Como implementar o reporte de incidentes NIS2 usando IA

Visão geral

Você aprenderá como usar IA para construir uma capacidade completa de reporte de incidentes NIS2 alinhada com o Artigo 23. Este guia abrange critérios de significância de incidentes, o fluxo de trabalho obrigatório de reporte em 24 horas/72 horas/um mês, modelos de alerta precoce, formatos de notificação de incidentes com indicadores de comprometimento (IOCs), estrutura do relatório final com análise de causa raiz, reporte voluntário de ameaças e quase-incidentes, e integração com o seu CSIRT nacional.

Para quem é este guia

Este guia é para:

• Gestores de resposta a incidentes e líderes de SOC que estão construindo fluxos de trabalho de reporte compatíveis com a NIS2
• CISOs responsáveis por estabelecer capacidades de reporte de incidentes que atendam aos prazos do Artigo 23
• Oficiais de conformidade que precisam garantir que os procedimentos de reporte satisfaçam as autoridades supervisoras
• Consultores de segurança que implementam reporte de incidentes para clientes em setores regulados pela NIS2
• Membros do órgão de gestão que devem entender suas obrigações de notificação e responsabilidades de supervisão

Antes de começar

Você precisará de:

• Uma conta no ISMS Copilot (teste gratuito disponível)
• A classificação da sua entidade NIS2 (essencial ou importante) -- veja How to Get Started with NIS2 Implementation Using AI
• Detalhes de contato do seu CSIRT nacional e autoridade competente
• Sua Política de Resposta a Incidentes (veja How to Create NIS2 Cybersecurity Policies Using AI para orientações de geração)
• Compreensão dos seus serviços e sistemas críticos a partir da sua avaliação de risco (veja How to Conduct NIS2 Risk Assessment Using AI)

Entendendo os requisitos de reporte de incidentes da NIS2

O que o Artigo 23 exige

O Artigo 23 da Diretiva NIS2 estabelece um framework de notificação em múltiplos estágios para incidentes significativos. Cada estágio tem requisitos de conteúdo e prazos específicos.

Estágio de reporte

Prazo

Requisitos de conteúdo

Destinatário

Alerta precoce

Dentro de 24 horas após tomar conhecimento

Indicação se o incidente é suspeito de ser causado por atos ilícitos ou maliciosos; indicação se pode ter impacto transfronteiriço

CSIRT nacional ou autoridade competente

Notificação de incidente

Dentro de 72 horas após tomar conhecimento

Atualização do alerta precoce; avaliação inicial de gravidade e impacto; indicadores de comprometimento (IOCs) quando disponíveis

CSIRT nacional ou autoridade competente

Relatório intermediário

A pedido do CSIRT ou autoridade competente

Atualizações relevantes sobre o tratamento e recuperação do incidente

CSIRT nacional ou autoridade competente

Relatório final

Dentro de um mês após a notificação do incidente

Descrição detalhada do incidente, incluindo gravidade e impacto; tipo de ameaça ou causa raiz; medidas de mitigação aplicadas e em andamento; impacto transfronteiriço (se aplicável)

CSIRT nacional ou autoridade competente

Relatório de progresso (para incidentes em andamento)

No marco de um mês se o incidente ainda estiver em andamento

Atualização de progresso em vez do relatório final; relatório final devido dentro de um mês após a resolução do incidente

CSIRT nacional ou autoridade competente

O que torna um incidente "significativo"

O Artigo 23(3) define um incidente significativo como aquele que:

• (a) Causou ou é capaz de causar grave perturbação operacional dos serviços ou perda financeira para a entidade em questão
• (b) Afetou ou é capaz de afetar outras pessoas naturais ou jurídicas, causando danos materiais ou não materiais consideráveis

A Comissão Europeia pode especificar ainda mais os critérios de significância dos incidentes por meio de atos de implementação. As leis nacionais de transposição também podem definir limiares adicionais ou mais específicos. Sua organização deve estabelecer critérios internos de classificação que estejam alinhados com essas definições.

Reporte voluntário

O Artigo 23 também incentiva o reporte voluntário de:

• Quase-incidentes (incidentes que poderiam ter causado impacto significativo, mas foram prevenidos ou detectados precocemente)
• Ameaças cibernéticas significativas que poderiam potencialmente causar incidentes significativos
• Informações que poderiam ajudar a prevenir ou responder a incidentes que afetem outras entidades

Passo 1: Construa sua matriz de classificação de incidentes

Definindo limiares de significância

Antes de poder reportar incidentes, você precisa de critérios claros e inequívocos para determinar quando um incidente ultrapassa o limiar de "significativo" e aciona as obrigações de reporte da NIS2.

1. Gere a matriz de classificação:

   "Crie uma matriz abrangente de classificação de incidentes para conformidade com o Artigo 23 da NIS2 em nossa organização do [setor] (classificada como entidade [essencial/importante]). A matriz deve incluir: quatro níveis de gravidade (Crítico, Alto, Médio, Baixo) com critérios claros para cada um. Para cada nível, defina: limiares de impacto operacional (duração da interrupção do serviço, porcentagem de usuários afetados, nível de degradação), limiares de impacto financeiro (custos diretos, potenciais penalidades regulatórias, perda de receita), limiares de impacto de dados (registros expostos, tipos de dados afetados, impacto na confidencialidade/integridade/disponibilidade), impacto em terceiros (número de entidades afetadas, potencial de impacto em todo o setor) e impacto reputacional. Marque claramente quais níveis de gravidade constituem um 'incidente significativo' sob o Artigo 23(3) e acionam o reporte obrigatório. Inclua exemplos específicos do setor para [setor]."

2. Crie a árvore de decisão de triagem:

   "Crie uma árvore de decisão para que os primeiros respondedores determinem rapidamente se um incidente é 'significativo' sob o Artigo 23 da NIS2 e requer reporte. A árvore de decisão deve ser utilizável dentro de 30 minutos após a detecção do incidente. Inclua perguntas sim/não cobrindo: (1) A entrega do serviço está afetada ou em risco? (2) O incidente afeta sistemas ou dados críticos? (3) Poderia impactar outras entidades ou pessoas? (4) Há evidência de atividade maliciosa ou ilícita? (5) Poderia haver impacto transfronteiriço? Mapeie cada caminho para um nível de classificação e as ações de resposta necessárias."

3. Gere exemplos de significância específicos do setor:

   "Gere 15 cenários realistas de incidentes para uma organização do [setor] e classifique cada um como significativo ou não significativo sob o Artigo 23(3) da NIS2. Para cada cenário, explique a lógica da classificação. Inclua cenários que sejam limítrofes para ilustrar onde são necessárias decisões subjetivas. Isso servirá como referência de treinamento para nossa equipe de resposta a incidentes."

Passo 2: Crie o fluxo de trabalho e modelo de alerta precoce de 24 horas

Entendendo os requisitos de alerta precoce

O alerta precoce é sua primeira comunicação com o CSIRT nacional ou autoridade competente. Ele deve ser submetido dentro de 24 horas após tomar conhecimento de um incidente significativo. Os requisitos de conteúdo são deliberadamente mínimos para permitir um reporte rápido -- não se espera que você tenha um quadro completo nesta fase.

1. Gere o modelo de alerta precoce:

   "Crie um modelo de relatório de alerta precoce do Artigo 23 da NIS2 para nossa organização do [setor]. O modelo deve incluir todos os campos exigidos dentro da janela de 24 horas: identificação da entidade reportante (nome, número de registro NIS2, setor, classificação da entidade), identificador do incidente (número de referência interno), data e hora da ciência, breve descrição do incidente (o que aconteceu, quais sistemas/serviços estão afetados), se o incidente é suspeito de ser causado por atos ilícitos ou maliciosos (sim/não/desconhecido com justificativa), se pode ter impacto transfronteiriço (sim/não/desconhecido com justificativa), avaliação inicial do escopo (serviços afetados, escopo geográfico), pessoa de contato para acompanhamento (nome, cargo, telefone, e-mail, canal de comunicação seguro) e quaisquer ações imediatas tomadas. Formate como um formulário que possa ser preenchido em 15 minutos."

2. Construa o fluxo de trabalho de alerta precoce:

   "Crie um fluxo de trabalho passo a passo para submeter o alerta precoce de 24 horas da NIS2, desde a detecção do incidente até a submissão do relatório. Inclua: (1) detecção e triagem inicial (meta: 2 horas), (2) avaliação de significância usando nossa matriz de classificação (meta: 1 hora), (3) notificação do gestor de incidentes e contato do CSIRT (meta: 30 minutos), (4) preenchimento do relatório de alerta precoce (meta: 30 minutos), (5) aprovação interna (CISO ou autoridade designada) (meta: 1 hora), (6) submissão ao CSIRT nacional via [especificar canal], (7) documentação e rastreamento interno. Inclua metas de tempo para cada etapa que garantam que o prazo de 24 horas seja cumprido com margem. Especifique quem é responsável por cada etapa, procedimentos de escalonamento se as pessoas responsáveis não estiverem disponíveis e procedimentos para fora do horário comercial."

Passo 3: Crie o fluxo de trabalho e modelo de notificação de incidente de 72 horas

Entendendo os requisitos de notificação

A notificação de incidente de 72 horas atualiza o alerta precoce com detalhes adicionais. Nesta fase, sua investigação deve ter progredido o suficiente para fornecer uma avaliação inicial de gravidade, impacto e indicadores de comprometimento.

1. Gere o modelo de notificação de incidente:

   "Crie um modelo de notificação de incidente do Artigo 23 da NIS2 (relatório de 72 horas) para nossa organização. Inclua todos os campos obrigatórios: referência ao relatório de alerta precoce, descrição atualizada do incidente com detalhes adicionais, avaliação inicial da gravidade do incidente (usando nossa matriz de classificação), avaliação de impacto -- serviços afetados, número de usuários/entidades impactados, duração da interrupção, indicadores de comprometimento (IOCs) quando disponíveis -- endereços IP, domínios, hashes de arquivos, assinaturas de malware, TTPs (Táticas, Técnicas, Procedimentos) observados, identificação do vetor de ataque (se conhecido nesta fase), sistemas e redes afetados, medidas iniciais de contenção e mitigação tomadas, avaliação de impacto transfronteiriço, avaliação se o incidente foi causado por atos ilícitos ou maliciosos, e qualquer assistência solicitada ao CSIRT. Inclua uma seção de apêndice para detalhes técnicos dos IOCs."

2. Construa o procedimento de coleta de IOCs:

   "Crie um procedimento para coletar e formatar indicadores de comprometimento (IOCs) para notificação de incidentes da NIS2. Aborde: tipos de IOCs a coletar (indicadores de rede, indicadores de host, indicadores de e-mail, indicadores de arquivo), métodos e ferramentas de coleta, preservação de evidências e cadeia de custódia, padrões de formatação de IOCs (STIX/TAXII quando aplicável), classificação de IOCs (marcação TLP -- Traffic Light Protocol), o que incluir no relatório de 72 horas versus o que compartilhar separadamente com o CSIRT, e como lidar com IOCs sensíveis que possam revelar a arquitetura interna."

3. Construa o fluxo de trabalho de notificação de 72 horas:

   "Crie um fluxo de trabalho detalhado para a notificação de incidente de 72 horas da NIS2. Inclua: atividades de investigação a serem concluídas dentro da janela de 72 horas (análise de logs, triagem forense, extração de IOCs, avaliação de impacto), etapas de coleta e preservação de evidências, processo de redação do relatório com contribuições da equipe técnica/jurídica/comunicações, cadeia de revisão e aprovação interna, procedimento de submissão ao CSIRT nacional, notificação de partes interessadas (órgão de gestão, partes afetadas, autoridades policiais se aplicável) e requisitos de documentação. Especifique funções, metas de tempo e procedimentos de escalonamento."

Passo 4: Crie o fluxo de trabalho e modelo de relatório final de um mês

Entendendo os requisitos do relatório final

O relatório final é a submissão mais abrangente e deve incluir uma descrição detalhada do incidente, análise de causa raiz e medidas de mitigação. Se o incidente ainda estiver em andamento no marco de um mês, submeta um relatório de progresso e entregue o relatório final dentro de um mês após a resolução do incidente.

1. Gere o modelo de relatório final:

   "Crie um modelo de relatório final de incidente do Artigo 23 da NIS2 para nossa organização do [setor]. Inclua todas as seções obrigatórias: (1) Resumo Executivo (visão geral de uma página para revisão pela gestão e autoridade), (2) Linha do Tempo do Incidente (sequência cronológica desde os primeiros indicadores até a detecção, reporte, contenção, erradicação e recuperação, com carimbos de data/hora), (3) Descrição Detalhada do Incidente (sistemas afetados, vetor de ataque, avaliação do ator da ameaça, dados impactados), (4) Avaliação de Gravidade e Impacto (avaliação final do impacto operacional, financeiro, de dados e em terceiros usando nossa matriz de classificação), (5) Análise de Causa Raiz (causa raiz técnica, fatores contribuintes, fraquezas sistêmicas que permitiram o incidente), (6) Indicadores de Comprometimento (lista completa de IOCs com classificações), (7) Medidas de Mitigação Aplicadas (contenção imediata, ações de erradicação, etapas de recuperação), (8) Medidas de Mitigação em Andamento (correções de longo prazo, melhorias de controle, aprimoramentos de monitoramento), (9) Avaliação de Impacto Transfronteiriço, (10) Lições Aprendidas e Recomendações Preventivas, (11) Apêndices (evidências técnicas, detalhes da linha do tempo, detalhes dos IOCs). Formate para submissão ao CSIRT nacional."

2. Gere a metodologia de análise de causa raiz:

   "Crie uma metodologia de análise de causa raiz (RCA) para relatórios finais de incidentes da NIS2. Inclua: técnicas de RCA adequadas para incidentes de cibersegurança (Cinco Porquês, Espinha de Peixe/Ishikawa, Análise de Árvore de Falhas), como distinguir entre causa próxima e causa raiz, modelo para documentar o processo e os resultados da RCA, como identificar fatores contribuintes (técnicos, de processo, humanos, organizacionais), como derivar ações corretivas e preventivas das causas raiz, e como apresentar os resultados da RCA para públicos técnicos e para o órgão de gestão."

3. Construa o modelo de relatório de progresso para incidentes em andamento:

   "Crie um modelo de relatório de progresso da NIS2 para incidentes ainda em andamento no marco de um mês. Inclua: referência ao alerta precoce e notificação originais, status atual do incidente e fase de resposta, avaliação de impacto atualizada, ações tomadas desde o último relatório, medidas de contenção e erradicação em andamento, cronograma estimado para resolução e quaisquer IOCs ou inteligência de ameaças atualizados."

Passo 5: Construa playbooks de resposta a incidentes

Playbooks específicos por cenário com reporte NIS2 integrado

Os playbooks traduzem sua política de resposta a incidentes e fluxos de trabalho de reporte em procedimentos específicos e acionáveis para tipos comuns de incidentes. Cada playbook deve integrar marcos de reporte da NIS2 no fluxo de trabalho de resposta.

1. Gere um playbook de ransomware:

   "Crie um playbook abrangente de resposta a incidentes de ransomware para nossa organização do [setor] com o reporte do Artigo 23 da NIS2 integrado. Inclua: gatilhos de detecção e indicadores iniciais, ações imediatas de contenção (isolamento de rede, rotação de credenciais), avaliação de significância NIS2 (ransomware que afeta serviços essenciais/importantes é quase sempre significativo), acionamento e preenchimento do alerta precoce de 24 horas, preservação de evidências (não desligue sistemas criptografados, capture a memória), etapas de investigação forense, extração de IOCs para a notificação de 72 horas, etapas de erradicação (remoção de malware, fechamento do vetor de acesso), recuperação a partir de backups offline, avaliação de exfiltração de dados, preenchimento da notificação de 72 horas com IOCs, coordenação com autoridades policiais, framework de decisão de pagamento de resgate, verificação de restauração de serviços, relatório final de um mês com análise de causa raiz e melhorias pós-incidente."

2. Gere um playbook de violação de dados:

   "Crie um playbook de resposta a incidentes de violação de dados com o reporte do Artigo 23 da NIS2 e do Artigo 33/34 do GDPR integrado. Aborde: detecção e avaliação de exposição de dados, determinação do escopo (quais dados, quantos registros, quais categorias), avaliação de significância NIS2, alerta precoce de 24 horas, contenção de acesso não autorizado, avaliação de notificação de 72 horas do GDPR (paralela ao reporte NIS2), coleta de IOCs e notificação de 72 horas da NIS2, avaliação de notificação de indivíduos afetados (Artigo 34 do GDPR), investigação forense e preservação de evidências, relatório final de um mês da NIS2 e coordenação entre o reporte ao CSIRT da NIS2 e a notificação à DPA do GDPR."

3. Gere um playbook de ataque DDoS:

   "Crie um playbook de resposta a incidentes de DDoS para nossa organização do [setor] com reporte NIS2. Aborde: detecção (anomalias de tráfego, monitoramento de degradação de serviço), avaliação inicial (ataque volumétrico, de protocolo ou de camada de aplicação), avaliação de significância NIS2 (a entrega de serviço para usuários/entidades dependentes está afetada?), alerta precoce de 24 horas se significativo, ativação de mitigação de DDoS (filtragem upstream, CDN, serviços de limpeza), monitoramento contínuo de serviço, coleta de IOCs (IPs de origem, assinaturas de ataque, padrões), notificação de 72 horas se aplicável, investigação de DDoS como potencial distração para um ataque secundário e análise pós-incidente."

4. Gere um playbook de comprometimento da cadeia de suprimentos:

   "Crie um playbook de resposta a incidentes de comprometimento da cadeia de suprimentos com reporte NIS2. Aborde: detecção de comprometimento do fornecedor (notificação do fornecedor, comportamento anômalo de software/serviços confiáveis), avaliação de impacto em nossos sistemas e dados, avaliação de significância NIS2 (comprometimento da cadeia de suprimentos frequentemente tem implicações transfronteiriças), alerta precoce de 24 horas com avaliação de impacto transfronteiriço, contenção (isolar conexões com o fornecedor afetado, revogar credenciais, bloquear atualizações comprometidas), coordenação com o fornecedor comprometido, avaliação de movimento lateral, extração e compartilhamento de IOCs, notificação de 72 horas, notificação de entidades a jusante que servimos e relatório final de um mês com lições aprendidas sobre a cadeia de suprimentos."

5. Gere playbooks específicos do setor:

   "Crie um playbook de resposta a incidentes de [comprometimento de OT/ICS | interrupção de sistemas de saúde | violação de sistemas financeiros | incidente na rede de energia] específico para nosso [setor] com o reporte NIS2 integrado. Aborde considerações específicas do setor, como [implicações de segurança, impacto em pacientes, estabilidade do mercado financeiro, continuidade do fornecimento de energia] e coordenação com autoridades específicas do setor."

Passo 6: Estabeleça integração e canais de comunicação com o CSIRT

Conectando-se ao seu CSIRT nacional

A NIS2 exige o reporte ao seu CSIRT nacional (Equipe de Resposta a Incidentes de Segurança Computacional) ou autoridade competente designada. Cada Estado-Membro da UE designou autoridades específicas e estabeleceu mecanismos de reporte.

1. Identifique sua autoridade de reporte:

   "Ajude-me a identificar a autoridade competente e o CSIRT da NIS2 para [Estado-Membro]. Forneça: o nome oficial e informações de contato, o portal de reporte ou método de submissão, quaisquer formatos de relatório específicos exigidos pela lei de transposição deste Estado-Membro, requisitos de registro e quaisquer canais de reporte específicos do setor que possam se aplicar ao nosso [setor]."

2. Crie o procedimento de comunicação com o CSIRT:

   "Crie um procedimento de comunicação com o CSIRT para nosso reporte de incidentes da NIS2. Aborde: métodos primários e de backup de submissão (portal online, e-mail, telefone), canais de comunicação seguros para compartilhar IOCs sensíveis, pessoas de contato designadas com o CSIRT (primária e backup, com cobertura 24/7), procedimentos de escalonamento se os canais de comunicação com o CSIRT estiverem indisponíveis, tratamento de orientações e instruções recebidas do CSIRT durante a resposta a incidentes, classificação e tratamento de informações (o que pode ser compartilhado, marcações TLP), e coordenação com o CSIRT para incidentes envolvendo múltiplas entidades."

Passo 7: Construa procedimentos de reporte voluntário

Reporte de quase-incidentes e ameaças

A NIS2 incentiva (mas não obriga) o reporte voluntário de quase-incidentes, ameaças cibernéticas significativas e informações que possam ajudar a prevenir incidentes que afetem outras entidades. Estabelecer o reporte voluntário demonstra governança de segurança madura e constrói boa vontade com as autoridades supervisoras.

1. Gere um procedimento de reporte voluntário:

   "Crie um procedimento de reporte voluntário de incidentes e ameaças para conformidade com a NIS2. Aborde: definição de quase-incidentes reportáveis (incidentes prevenidos por controles, campanhas de phishing detectadas, tentativas de intrusão bloqueadas), definição de ameaças reportáveis (inteligência sobre ameaças iminentes ao nosso setor, vulnerabilidades recém-descobertas em sistemas amplamente utilizados), formato de reporte para notificações voluntárias (mais leve do que os relatórios obrigatórios, focado em inteligência acionável), processo interno para decidir quando submeter relatórios voluntários, considerações de anonimização quando aplicável e benefícios do reporte voluntário (relacionamento com o CSIRT, compartilhamento de inteligência setorial)."

Passo 8: Implemente métricas de reporte e melhoria contínua

Medindo a eficácia do reporte de incidentes

O Artigo 21(2)(f) exige a avaliação da eficácia das suas medidas de cibersegurança. Sua capacidade de reporte de incidentes deve ser medida e melhorada regularmente.

1. Defina KPIs de reporte:

   "Crie um conjunto de KPIs para medir a eficácia da nossa capacidade de reporte de incidentes da NIS2. Inclua: tempo médio para detectar incidentes significativos, tempo médio da detecção à submissão do alerta precoce, porcentagem de alertas precoces submetidos dentro de 24 horas, porcentagem de notificações submetidas dentro de 72 horas, porcentagem de relatórios finais submetidos dentro de um mês, pontuação de qualidade para completude e precisão do relatório, número de incidentes corretamente classificados como significativos vs. não significativos, pontuações de desempenho em exercícios de mesa, tempo para estabelecer comunicação com o CSIRT durante incidentes e frequência de reporte de métricas de incidentes ao órgão de gestão."

2. Crie o procedimento de revisão pós-incidente:

   "Crie um procedimento de revisão pós-incidente que avalie especificamente nosso desempenho no reporte da NIS2. Após cada incidente significativo (e incidentes não significativos selecionados), revise: (1) o incidente foi corretamente classificado quanto à significância para a NIS2? (2) todos os prazos de reporte foram cumpridos? (3) o conteúdo do relatório estava completo e preciso? (4) a comunicação com o CSIRT foi eficaz? (5) todas as partes interessadas internas foram notificadas adequadamente? (6) quais melhorias são necessárias em nossos fluxos de trabalho de detecção, triagem ou reporte? Documente os achados e acompanhe as ações corretivas."

Desafios comuns no reporte de incidentes e soluções

Desafio

Risco

Solução

Critérios de significância pouco claros

Reporte tardio ou excesso de reportes

Implemente a matriz de classificação e a árvore de decisão com exemplos específicos do setor

Falta de cobertura fora do horário comercial

Perda do prazo de 24 horas para incidentes detectados fora do horário comercial

Estabeleça uma escala de plantão 24/7 com autoridade para submeter alertas precoces

Lacunas na coleta de IOCs

Notificação de 72 horas incompleta

Integre a coleta de IOCs aos procedimentos forenses padrão; pré-configure ferramentas de coleta

Profundidade da análise de causa raiz

Relatórios finais que não satisfazem as autoridades supervisoras

Use metodologia estruturada de RCA; procure além da causa próxima para fatores sistêmicos

Coordenação GDPR/NIS2

Notificações duplicadas ou conflitantes para diferentes autoridades

Crie um fluxo de trabalho unificado de notificação que aborde tanto os requisitos da NIS2 quanto do GDPR

Falha na comunicação com o CSIRT

Impossibilidade de submeter relatórios durante um incidente grave

Estabeleça canais de comunicação de backup; teste regularmente

Preocupações legais com a divulgação

Reporte atrasado devido a gargalos de revisão legal

Pré-aprove relatórios modelos; envolva o jurídico no desenvolvimento dos playbooks, não na aprovação por incidente

Próximos passos

Com sua capacidade de reporte de incidentes estabelecida, você abordou uma das áreas mais sensíveis ao tempo e mais escrutinadas da conformidade com a NIS2.

Continue com o próximo guia desta série:

• Segurança da cadeia de suprimentos: Veja How to Manage NIS2 Supply Chain Security Using AI para construir a capacidade de gestão de risco da cadeia de suprimentos exigida pelo Artigo 21(2)(d) -- incluindo como incidentes na cadeia de suprimentos se integram aos seus fluxos de trabalho de reporte

Se você ainda não completou as etapas anteriores, veja:

• How to Get Started with NIS2 Implementation Using AI para definição de escopo e configuração de governança
• How to Conduct NIS2 Risk Assessment Using AI para a avaliação de risco que informa sua classificação de incidentes
• How to Create NIS2 Cybersecurity Policies Using AI para o framework de políticas que rege sua resposta a incidentes

Para prompts prontos para uso de reporte de incidentes, explore a NIS2 Directive Prompt Library. Para uma visão abrangente de todos os requisitos da NIS2, veja o NIS2 Compliance Guide for In-Scope Companies.

Obtendo ajuda

Para suporte adicional com o reporte de incidentes da NIS2:

• Pergunte ao ISMS Copilot: Use seu espaço de trabalho da NIS2 para perguntas sobre reporte de incidentes, personalização de modelos e desenvolvimento de playbooks
• Simule incidentes: Peça ao ISMS Copilot para gerar cenários realistas de incidentes para exercícios de mesa e treinamento da equipe
• Revise relatórios: Carregue rascunhos de relatórios de incidentes e peça uma revisão de completude em relação aos requisitos do Artigo 23
• Requisitos nacionais: Pergunte sobre formatos de reporte específicos, portais ou requisitos adicionais impostos pela lei de transposição do seu Estado-Membro