Seguir As obrigações de detecção regulatória são os resultados de segurança que DORA, NIS2, PCI DSS v4.0.1, e as regras de divulgação da SEC exigem que uma organização alcance e comprove por meio de detecção, monitoramento, registro e divulgação.
Nenhum desses quatro regimes prescreve uma ferramenta de detecção específica. Apenas o DORA menciona a detecção como uma obrigação autônoma. Cada estrutura requer um resultado: detecção oportuna, monitoramento contínuo, registro estruturado ou divulgação oportuna. A capacidade de detecção é o que a evidência implica, não um controle que qualquer regulador exija especificamente.
MITRE ATT&CK organiza essa evidência em uma estrutura que um auditor pode consultar por categoria de comportamento adversário. ATT&CK não é exigido por DORA, NIS2, PCI DSS ou pelas regras da SEC.
DORA é lex specialis ou uma lei específica que tem precedência sobre uma lei geral. O Artigo 1(2) de DORA faz dele um ato legal da União específico para o setor para os fins do Artigo 4 da NIS2. Uma entidade financeira no escopo do DORA aplica o DORA para a gestão de riscos de TIC e relatórios de incidentes. A NIS2 alcança a cadeia de suprimentos não financeira de um banco, não o próprio banco.
Qual evidência de detecção apoia as obrigações sob PCI DSS 4.0 e DORA?
Ambos PCI DSS v4.0.1 e o DORA tratam a detecção como um meio para um fim evidencial. A regulamentação questiona se as detecções geram os registros que a obrigação de monitoramento exige, não se as detecções existem.
Cinco classes de evidência carregam essa prova. Ambos os regimes exigem eles em substância.
| Classe de Evidência | PCI DSS v4.0.1 | DORA |
|---|---|---|
| Fontes de logs coletadas | Requisito 10: capturar logs de auditoria, reter histórico | Artigo 9(1): monitorar e controlar continuamente a segurança e o funcionamento dos sistemas de TIC; Artigo 10(3): monitorar atividade do usuário, anomalias de TIC e incidentes relacionados a TIC |
| Regras implantadas, com proprietário | Requisito 11: detecção/prevenção de intrusão, detecção de alteração em vigor | Artigo 10: múltiplas camadas de controle, limites de alerta e critérios definidos |
| Prova de disparo | Requisito 10: revisar logs, detectar falhas nos sistemas de controle | Artigo 10: alertas disparados e atingiram a equipe responsável |
| Histórico de alterações | Requisito 11: detecção de alterações e adulterações | Artigo 17: processo documentado de gerenciamento de incidentes com acompanhamento da causa raiz |
| Relatório de cobertura com data | Requisito 10.5.1: histórico de logs de auditoria retido por pelo menos 12 meses, os três meses mais recentes imediatamente disponíveis (biblioteca de documentos do PCI SSC) | Artigo 10(1): mecanismos de detecção regularmente testados de acordo com o Artigo 25 |
O PCI DSS v4.0 foi aposentado em 31 de dezembro de 2024 e o PCI DSS v4.0.1 é a única versão ativa (PCI SSC, junho de 2024). Os 51 requisitos com data futura entraram em vigor em 31 de março de 2025 (PCI SSC, agosto de 2024). O H2 acima usa “PCI DSS 4.0” para coincidir com a consulta do pesquisador.
Uma regra de detecção que é implantada mas não gera um registro auditável é invisível para um avaliador.
Quais obrigações de detecção e monitoramento o DORA, NIS2, PCI DSS 4.0 e as regras de divulgação da SEC realmente impõem?
Cada regime impõe uma obrigação de resultado em vez de um mandato de ferramenta. A tabela abaixo mapeia cada obrigação para a evidência de detecção que ela implica.
| Regime | Artigo ou Requisito | Obrigação | Evidência de detecção implícita |
|---|---|---|---|
| DORA | Art 9(1), Art 10(3) | Monitorar e controlar continuamente a segurança e o funcionamento dos sistemas de TIC (Art 9(1)); monitorar atividade do usuário, anomalias de TIC e incidentes relacionados a TIC (Art 10(3)) | Inventário de fontes de logs, registros de coleta contínua |
| DORA | Art 10(1), (2) | Detectar atividades anômalas; múltiplas camadas de controle com limites e critérios de alerta, incluindo alertas automáticos para a equipe responsável por resposta a incidentes; mecanismos de detecção regularmente testados sob o Artigo 25 | Inventário de regras com proprietários, justificativa de limiar, prova de alertas alcançaram os respondentes, registros de teste |
| DORA | Art 17 | Detectar, gerenciar e notificar incidentes relacionados a TIC com acompanhamento da causa raiz | Documentação de processo, registros de detecção e manuseio por incidente |
| DORA | Art 19 + Regulamento Delegado (UE) 2025/301 | Relatar incidentes importantes à autoridade competente | Registro de detecção e classificação com carimbo de data/hora (notificação inicial dentro de 4 horas após classificar o incidente como importante e não mais tardar do que 24 horas após a conscientização; relatório intermediário dentro de 72 horas após a notificação inicial; relatório final dentro de um mês após o relatório intermediário) |
| NIS2 | Art 21(2) | Medidas de gerenciamento de riscos incluindo manuseio de incidentes (ponto (b)) e políticas para avaliar a eficácia das medidas (ponto (f)); responsabilidades de monitoramento e registro estão nas regras de implementação abaixo, não no próprio Artigo 21 | Medidas documentadas, registros de detecção |
| NIS2 | Art 23(4) | Notificação de incidente significativo | Alerta antecipado dentro de 24 horas após a conscientização, notificação de incidente dentro de 72 horas, relatório final não mais tardar que um mês após a notificação de incidente |
| NIS2 | Regulamento de Implementação (UE) 2024/2690 | Monitoramento e registro (seção 3.2 do Anexo) para os onze tipos de entidades no Artigo 1(1), incluindo provedores de serviços de segurança gerenciada | Registros explícitos de log para entidades cobertas |
| PCI DSS v4.0.1 | Req 10 | Registros de logs e monitoramento de todo o acesso aos componentes do sistema e dados de titulares de cartão | Logs de auditoria revisados pelo menos diariamente (10.4.1), revisão de logs automatizada (10.4.1.1), histórico de logs retido (10.5.1), falhas dos sistemas críticos de controle de segurança detectadas, relatadas e respondidas prontamente (10.7, 10.7.2); texto no biblioteca de documentos do PCI SSC |
| PCI DSS v4.0.1 | Req 11 | Testar regularmente a segurança dos sistemas e redes | Registros de detecção e prevenção de intrusão (11.5.1), alertas de detecção de alteração (11.5.2), alertas de detecção de alteração e adulteração na página de pagamento (11.6.1) |
| SEC | 8-K Item 1.05 | Divulgar incidentes materiais dentro de quatro dias úteis após a determinação da materialidade, que deve ser feita sem atraso injustificado após a descoberta (Formulário 8-K, Item 1.05) | Processo de determinação de materialidade, registros de detecção de incidentes |
| SEC | S-K Item 106 | Descrever os processos para avaliar, identificar e gerenciar riscos cibernéticos materiais no 10-K anual (Item 1C) | Processo documentado de identificação de riscos incluindo capacidade de detecção |
DORA (Regulamento (UE) 2022/2554, em aplicação desde 17 de janeiro de 2025, é diretamente aplicável. Seus cronômetros de relatórios são estabelecidos por Regulamento Delegado (UE) 2025/301: notificação inicial dentro de 4 horas após classificar um incidente como importante e não mais tardar do que 24 horas após a conscientização, um relatório intermediário dentro de 72 horas após a notificação inicial, e um relatório final dentro de um mês após o relatório intermediário. Porque o primeiro cronômetro começa na detecção e classificação, o próprio cronograma do incidente é uma evidência auditável.
NIS2 (Diretiva (UE) 2022/2555) vincula-se através da lei de transposição de cada Estado-Membro, não diretamente. O prazo de transposição era 17 de outubro de 2024 (Artigo 41). Em 7 de maio de 2025, a Comissão Europeia enviou pareceres fundamentados para 19 Estados-Membros por não notificarem a transposição completa, e em 8 de julho de 2026, ela encaminhou a Irlanda, Espanha, França e Países Baixos ao Tribunal de Justiça. Em 20 de janeiro de 2026, a Comissão propôs emendas à NIS2 (COM(2026) 13) que abordam o Artigo 21(5) e adicionam parágrafos sobre ransomware ao Artigo 23, deixando as medidas do Artigo 21(2) e os cronômetros de relatórios do Artigo 23(4) inalterados. A obrigação que um comprador enfrenta depende da lei de transposição de seu Estado-Membro.
Regulamento de Implementação (UE) 2024/2690, publicado em 18 de outubro de 2024 e em vigor a partir de 7 de novembro de 2024, estabelece requisitos explícitos de monitoramento e registro (seção 3.2 do Anexo) para provedores de serviços DNS, registros de nomes TLD, computação em nuvem, centros de dados, redes de entrega de conteúdo, provedores de serviços gerenciados e de segurança gerenciada, mercados online, motores de busca, plataformas de redes sociais e provedores de serviços de confiança. Isso atinge MSSPs como entidades reguladas por direito próprio, distintas das obrigações de seus clientes.
PCI DSS v4.0.1 é a única versão ativa. Os requisitos 10 e 11 carregam as obrigações de detecção e monitoramento.
SEC (regra final Release 33-11216, adotado em 26 de julho de 2023, é uma regra de governança e divulgação, não um mandato de controle de detecção. A detecção é derivada: um registrante não pode determinar a materialidade sem a capacidade de detectar e avaliar incidentes. A conformidade com o Item 1.05 foi exigida a partir de 18 de dezembro de 2023 para a maioria dos registrantes e a partir de 15 de junho de 2024 para pequenas empresas de relatórios.
Que evidência os auditores geralmente procuram para confirmar que nossos sistemas de detecção são eficazes?
Cinco classes de evidências recorrem em todos esses regimes. Uma porcentagem de cobertura sozinha não é evidência para nenhum deles.
| # | Classe de Evidência | O que isso prova |
|---|---|---|
| 1 | Fontes de logs coletadas | Quais telemetrias são ingeridas, de quais sistemas, e que a coleta é contínua. O auditor verifica se o monitoramento está em execução, não se foi configurado uma vez. |
| 2 | Regras implantadas | Regras de detecção em vigor, cada uma mapeada para a obrigação que apoia e para sua ATT&CK técnica onde aplicável, com um proprietário. |
| 3 | Prova de disparo | Regras disparadas em eventos reais ou emulados e alertas chegaram aos respondentes. Uma regra implantada que nunca disparou é não testada do ponto de vista do auditor. |
| 4 | Histórico de alterações | Quem alterou uma regra, quando e por que: controle de versão, trilha de revisão e justificativa documentada para cada alteração. |
| 5 | Relatório de cobertura com data | Relatório pontual com uma data, para que tendência e atualidade sejam comprováveis. Um relatório sem data não prova nada sobre quando a cobertura existiu. |
ATT&CK funciona como a transição que torna essa evidência consultável por comportamento adversário. Um ID de técnica é um metadado anexado a evidências já existentes (fontes de dados, regras implantadas, registros de disparo) para que a evidência se torne recuperável por categoria de comportamento. ATT&CK não é exigido por qualquer um desses quatro regimes. Ele organiza evidências contra as obrigações que impõem.
Você pode mostrar a um auditor quem alterou uma regra, quando e por quê?
Detecção-como-Código responde a isso. Cada regra de detecção é um artefato controlado por versão no controle de origem. O histórico de alterações registra autor, carimbo de data/hora, aprovação de revisão e a razão para a alteração.
Este rastro mapeia para obrigações específicas:
- O Artigo 17 do DORA exige um processo documentado de gerenciamento de incidentes com acompanhamento da causa raiz.
- PCI DSS v4.0.1 O Requisito 11 inclui detecção de alterações e adulterações.
- O Item 106 da SEC espera que um registrante descreva seus processos de identificação de riscos.
Cada estrutura pergunta se a organização governa as regras de detecção como artefatos controlados, não apenas se as regras existem.
O teste operacional: dada uma regra que foi disparada no último trimestre, a equipe pode produzir sua linhagem completa? Quem a escreveu, quem a revisou, quando foi modificada pela última vez, por quê, qual obrigação ela mapeia e qual técnica ela aborda. Uma plataforma de conteúdo de detecção que gerencia regras como código versionado produz este rastro como um subproduto das operações normais.
Onde as regras são editadas em um console sem controle de versão, o auditor não tem procedência para o estado atual da regra. A governança com Detecção-como-Código remove essa ambiguidade por construção.
Como a cobertura de detecção se torna um item de linha de conformidade?
A capacidade de detecção tende a ficar dentro dos orçamentos operacionais, visível para o gerente do SOC, invisível para o CFO. Três fatos tornam a cobertura uma conversa no conselho.
- Os cronômetros de relatório começam na detecção. O cronômetro de classificação de 4 horas do DORA e o cronômetro de materialidade de quatro dias úteis da SEC começam quando a organização detecta ou toma conhecimento. A detecção mais rápida é o começo da linha do tempo de conformidade.
- A evidência de detecção é auditável. As cinco classes de evidências acima são o que um auditor revisa. Produzi-las custa tempo e equipe, seja a equipe construindo suas próprias regras ou se inscrevendo em uma fonte de conteúdo de detecção.
- O tempo para cobertura é mensurável. A janela entre uma técnica se tornar pública e uma detecção validada disparada no próprio ambiente da organização é rastreável.
Uma equipe de engenharia solicita capacidade de detecção em termos de pessoal e ferramentas. Uma equipe de conformidade solicita isso em termos de produção de evidências. O segundo enquadramento liga o gasto com detecção a uma obrigação regulatória que o conselho já acompanha.
Uma auditoria de postura SIEM produz o mapa de cobertura que os auditores pedem: regras mapeadas para o MITRE ATT&CK, fontes de logs mapeadas para a mesma matriz, e as lacunas listadas com um plano.
Onde isso não é válido
Várias limitações se aplicam.
Nem toda obrigação se mapeia para detecção. O Item 1.05 da SEC exige divulgação, não controles específicos. O Artigo 21 da NIS2 e o DORA incluem segurança da cadeia de suprimentos, continuidade de negócios e gerenciamento de acesso. Nenhum destes se mapeia para técnicas ATT&CK. O ATT&CK organiza o subconjunto de detecção e monitoramento, não a superfície plena de conformidade.
A transposição da NIS2 está incompleta. Onde uma lei de transposição de um Estado-Membro não está em vigor, os Artigos 21 e 23 da NIS2 não são aplicáveis localmente. As emendas propostas em janeiro de 2026 não renumeram os Artigos 21 ou 23.
As regras da SEC estão sendo contestadas. The pedido de rescisão contra o Item 1.05, apresentado em 22 de maio de 2025 por cinco associações de comércio bancário e de títulos (Arquivo SEC nº 4-856), permanece sem resolução: em 21 de setembro de 2026, a SEC não propôs nenhuma emenda ao Item 1.05, embora os peticionários tenham renovado o pedido em uma carta de comentários de abril de 2026 no âmbito da revisão do Regulamento S-K da Comissão. Uma declaração de 21 de maio de 2024 por Erik Gerding, então Diretor da Divisão de Finanças Corporativas, esclareceu que o Item 1.05 é reservado para incidentes que um registrante determinou serem materiais e encorajou a divulgação de outros incidentes sob um item diferente, como o Item 8.01; a Divisão prosseguiu com Interpretações de Conformidade e Divulgação em 24 de junho de 2024.
Os números de sub-requisitos seguem v4.0.1. Os sub-requisitos do PCI DSS citados aqui (10.4.1, 10.4.1.1, 10.5.1, 10.7, 10.7.2, 11.5.1, 11.5.2, 11.6.1) usam a numeração v4.0.1; o próprio padrão está na biblioteca de documentos do PCI SSC, e o Requisito 10.7.2 aplica-se a todas as entidades a partir de 31 de março de 2025.
O ATT&CK é um cruzamento, não uma obrigação regulatória. Mapear detecções para técnicas ATT&CK organiza evidências. Não cumpre por si só uma obrigação regulatória, e nenhum quadro examinado aqui exige isso.
DORA é lex specialis para entidades financeiras. Um banco no escopo do DORA não aplica os Artigos 21 e 23 da NIS2 além disso para sua própria gestão de risco de TIC e relatórios de incidentes. A NIS2 alcança a cadeia de suprimentos não financeira de um banco, não as operações de TIC do próprio banco.
LISTA DE VERIFICAÇÃO DE EVIDÊNCIAS DE AUDITORIA: OBRIGAÇÕES DE DETECÇÃO
1. FONTES DE LOGS COLETADAS
[ ] Inventário de fontes de telemetria ingeridas
[ ] Evidência de coleta contínua (não pontual)
[ ] Cada fonte mapeada para os sistemas, ativos e
obrigações que cobre
2. REGRAS IMPLANTADAS
[ ] Inventário de regras de detecção com proprietários nomeados
[ ] Cada regra mapeada para a obrigação regulatória que apoia
[ ] Cada regra mapeada para técnica ATT&CK onde aplicável
(cruzamento, não exigido por regulamentação)
[ ] Limiares de alerta documentados com justificativa
3. PROVA DE DISPARO
[ ] Evidência de que as regras dispararam em eventos reais ou emulados
[ ] Registros de que alertas alcançaram respondedores designados
[ ] Registros de teste datados para mecanismos de detecção
(Artigo 10 do DORA)
4. HISTÓRICO DE ALTERAÇÕES
[ ] Controle de versão para cada regra de detecção
(Detecção-como-Código)
[ ] Autor, revisor, carimbo de data/hora e justificativa por alteração
[ ] Trilhas de revisão e aprovação
[ ] Registros de detecção de mudanças e adulterações
5. RELATÓRIO DE COBERTURA DATADO
[ ] Relatório de cobertura pontual com uma data
[ ] Cobertura medida contra conjunto de técnicas priorizadas,
não a matriz ATT&CK completa
[ ] Dados de tendência mostrando cobertura ao longo do tempo
[ ] Relatórios por ambiente (não um número agregado)
ITENS ESPECÍFICOS DO REGIME
[ ] DORA: limiares de alerta documentados com justificativa
(Artigo 10)
[ ] DORA: carimbos de incidente nos cronômetros de relatório
(4h desde classificação / 24h desde conscientização,
72h intermediário, 1 mês final)
[ ] NIS2: evidência mapeada para a lei nacional transposta,
não apenas o texto da diretiva
[ ] PCI DSS v4.0.1: retenção de logs por sub-requisitos aplicáveis
[ ] SEC: processo de determinação de materialidade documentado
(Item 1.05)
[ ] SEC: supervisão do conselho e papel de gerenciamento descritos
(Item 106)
NOTAS
- ATT&CK é o cruzamento usado para organizar esta evidência.
Não é exigido por DORA, NIS2, PCI DSS ou regras da SEC.
- DORA é lex specialis: um banco no escopo do DORA aplica DORA,
não os Artigos 21 e 23 da NIS2, para a gestão de riscos de TIC.
- PCI DSS v4.0.1 é a única versão ativa
(v4.0 aposentado em 31 de dezembro de 2024).
- Cada especificidade regulatória neste documento é validada
por ciso-cto-sme antes de publicar.
FAQ
Qual evidência de detecção apoia as obrigações sob PCI DSS 4.0 e DORA?
Ambos os regimes exigem evidência de detecção e monitoramento contínuos, não apenas evidência de que ferramentas de detecção estão implantadas. As cinco classes de evidência são: fontes de logs coletadas, regras de detecção implantadas com proprietários, prova de que essas regras disparam, histórico de alterações com controle de versão e um relatório de cobertura datado. MITRE ATT&CK organiza esta evidência por categoria de comportamento adversário. ATT&CK não é exigido por nenhum dos dois quadros.
Que evidência os auditores procuram para confirmar que os sistemas de detecção são eficazes?
Auditores procuram por cinco classes de evidências: quais fontes de telemetria são coletadas e que a coleta é contínua, regras de detecção mapeadas para obrigações e técnicas ATT&CK com proprietários nomeados, prova de que essas regras disparam em eventos reais ou emulados, histórico de alterações com controle de versão para cada regra, e um relatório de cobertura datado e pontual. Uma porcentagem de cobertura sozinha, sem os registros de suporte subjacentes, não é evidência.
O mapeamento de detecções para MITRE ATT&CK satisfaz um regulador?
ATT&CK é o cruzamento que organiza evidências de detecção por comportamento adversário. Ele torna as evidências consultáveis e reportáveis por técnica. Não cumpre por si só nenhuma obrigação regulatória. DORA, NIS2, PCI DSS e as regras da SEC pedem por evidências de operação: monitoramento, detecção, registro e divulgação. ATT&CK organiza essa evidência. Nenhum dos quadros examinados aqui exige isso.
Quais são os cronômetros de relato de incidentes sob DORA e NIS2?
Sob o DORA, o Regulamento Delegado (UE) 2025/301 estabelece os cronômetros para incidentes importantes: notificação inicial dentro de 4 horas após classificar o incidente como importante (não mais tardar do que 24 horas após a conscientização), um relatório intermediário dentro de 72 horas após a notificação inicial, e um relatório final dentro de um mês após o relatório intermediário. Sob o NIS2, incidentes significativos requerem um alerta antecipado dentro de 24 horas após a conscientização, uma notificação de incidente dentro de 72 horas, e um relatório final não mais tardar que um mês após a notificação de incidente. Ambos os cronômetros começam na detecção, tornando o próprio carimbo de detecção um registro auditável.
O Custom Content Engineering do SOC Prime implementa detecções em seu SIEM ou EDR e fornece documentação de alto nível de seu propósito, função e uso.
