Como implementar relatórios de incidentes DORA usando IA
Você aprenderá como implementar os requisitos de relatório de incidentes relacionados a TIC da DORA sob os Artigos 17-23 usando IA. Este guia abrange critérios de classificação de incidentes…
Visão geral
Você aprenderá como implementar os requisitos de relatório de incidentes relacionados a TIC da DORA sob os Artigos 17-23 usando IA. Este guia abrange critérios de classificação de incidentes, os prazos obrigatórios de relatório de 4 horas/72 horas/1 mês, modelos de notificação, procedimentos de análise de causa raiz e integração com seus processos existentes de gestão de incidentes, com prompts específicos do ISMS Copilot para gerar cada componente.
Para quem é este guia
Este guia é para:
- Gestores de resposta a incidentes e líderes de SOC responsáveis pela detecção e classificação de incidentes de TIC
- Oficiais de conformidade que gerenciam notificações regulatórias de incidentes
- CISOs que supervisionam programas de gestão de incidentes em entidades financeiras
- Gestores de risco que avaliam o impacto de incidentes e acompanham a remediação
- Consultores que implementam relatórios de incidentes DORA para clientes de entidades financeiras
Antes de começar
Você precisará de:
- Uma conta no ISMS Copilot (teste gratuito disponível)
- Seu framework de gestão de risco de TIC estabelecido conforme How to build a DORA ICT risk management framework using AI
- Seu inventário de ativos de TIC com classificações de criticidade (necessário para avaliação de impacto de incidentes)
- Seus procedimentos existentes de resposta a incidentes e quaisquer processos atuais de relatórios regulatórios
- Compreensão dos canais e formatos de relatório de sua autoridade competente
- Acesso à sua equipe de resposta a incidentes, SOC e função de conformidade
Obrigações críticas de tempo: A DORA exige notificação inicial de incidentes graves relacionados a TIC dentro de 4 horas após a classificação. Este é um dos prazos de relatório mais rigorosos na regulamentação financeira da UE. Seus procedimentos de classificação e relatório de incidentes devem ser pré-construídos, testados e compreendidos por todos os funcionários relevantes antes que um incidente ocorra.
Compreendendo os requisitos de relatório de incidentes da DORA
Análise artigo por artigo
O Capítulo III da DORA (Artigos 17-23) estabelece um regime abrangente de gestão e relatório de incidentes. Cada artigo aborda um aspecto específico do processo:
Article
Title
Key requirements
Key deliverables
Art 17
ICT-related incident management process
Estabelecer processo de gestão de incidentes com indicadores de alerta precoce, procedimentos e funções
Documento do processo de gestão de incidentes, matriz de funções
Art 18
Classification of ICT-related incidents and cyber threats
Classificar incidentes usando critérios prescritos (grave vs. não grave)
Matriz de classificação, critérios de gravidade, fluxograma de decisão
Art 19
Reporting of major ICT-related incidents
Relatório em três etapas: inicial (4h), intermediário (72h), final (1 mês)
Modelos de relatório, procedimentos de escalonamento, fluxos de trabalho de submissão
Art 20
Harmonisation of reporting content and templates
Formatos de relatório padronizados conforme RTS
Modelos de relatório preenchidos alinhados aos formatos RTS
Art 21
Centralisation of reporting
Relatório através de um único Hub da UE (requisito futuro)
Procedimentos de canal de relatório
Art 22
Supervisory feedback
Receber e agir conforme feedback supervisório
Processo de integração de feedback
Art 23
Notification of significant cyber threats
Notificação voluntária de ameaças cibernéticas significativas
Procedimentos de notificação de ameaças
O cronograma de relatório em três etapas
Compreender o cronograma de relatório da DORA é crítico para construir seus procedimentos:
Report stage
Deadline
Trigger
Content required
Key challenge
Initial notification
Dentro de 4 horas após classificar como grave
Incidente classificado como grave
Resumo do incidente, fundamentação da classificação, avaliação inicial de impacto, serviços afetados
Velocidade de classificação e submissão
Intermediate report
Dentro de 72 horas da notificação inicial
Investigação em andamento
Impacto atualizado, análise de causa raiz (inicial), medidas de contenção, status de recuperação
Fornecer análise significativa enquanto o incidente pode estar em andamento
Final report
Dentro de 1 mês da notificação inicial
Resolução do incidente
Causa raiz completa, impacto total (financeiro, operacional, reputacional), ações de remediação, lições aprendidas
Análise abrangente e evidências de remediação
O prazo de 4 horas começa a partir do momento da classificação como incidente grave, não do momento da detecção. No entanto, a DORA também exige processos rápidos de detecção e classificação. Se a sua classificação for atrasada de forma irrazoável, os reguladores podem considerar isso como não conforme com o espírito do requisito de relatório.
Passo 1: Estabeleça seu processo de gestão de incidentes (Artigo 17)
Processo central de gestão de incidentes
O Artigo 17 exige um processo abrangente de gestão de incidentes relacionados a TIC. Este processo deve ser integrado às suas capacidades de detecção (Artigo 10) e ao seu framework mais amplo de gestão de risco de TIC.
-
Abra seu espaço de trabalho DORA no ISMS Copilot
-
Gere o processo de gestão de incidentes:
"Crie um processo abrangente de gestão de incidentes relacionados a TIC para um [tipo de entidade] que atenda ao Artigo 17 da DORA. Inclua: propósito, escopo e objetivos do processo, fases do ciclo de vida do incidente (detecção, triagem, classificação, contenção, erradicação, recuperação, revisão pós-incidente), funções e responsabilidades (comandante do incidente, líder técnico, líder de comunicações, relatórios regulatórios/compliance, ligação com o órgão de gestão), indicadores de alerta precoce e gatilhos de detecção (vinculados ao monitoramento do Artigo 10), matriz de escalonamento por gravidade do incidente, protocolos de comunicação (equipes internas, órgão de gestão, clientes, autoridade competente), integração com processos existentes de gestão de serviços de TI (ITSM), requisitos de documentação e preservação de evidências, critérios de ativação do processo e árvores de decisão, e métricas de desempenho do processo. Forneça o processo em formato pronto para fluxograma com pontos de decisão claros."
-
Defina a estrutura da equipe de resposta a incidentes:
"Defina a estrutura da equipe de resposta a incidentes de TIC (IRT) para um [tipo de entidade] com [número] de funcionários. Inclua: composição da equipe (equipe principal, equipe estendida, escala de plantão), critérios de seleção e níveis de autoridade do líder da equipe, procedimentos de ativação (horário comercial e fora de horário), canais e ferramentas de comunicação, modelo de diretório de contatos dos membros da equipe, requisitos de treinamento e exercícios, e integração com partes externas (reguladores, autoridades policiais, provedores forenses, provedores de TIC terceirizados). Aborde os requisitos de cobertura 24/7 para cumprir o prazo de notificação de 4 horas."
Dica profissional: O relógio de relatório de 4 horas começa na classificação, então seu processo de triagem para classificação é crítico. Projete-o para ser concluído em no máximo 1-2 horas, deixando 2-3 horas para preparação e submissão do relatório. Pré-preencha os modelos de relatório com dados organizacionais permanentes para reduzir o tempo de preparação sob pressão.
Passo 2: Construa sua matriz de classificação de incidentes (Artigo 18)
Critérios de classificação de incidentes graves
O Artigo 18 estabelece critérios para classificar incidentes relacionados a TIC como graves. Os Padrões Técnicos Regulatórios (RTS) fornecem limiares detalhados de materialidade. Sua matriz de classificação deve operacionalizar esses critérios para tomada de decisão rápida durante um incidente.
-
Gere a matriz de classificação:
"Crie uma matriz de classificação de incidentes relacionados a TIC para um [tipo de entidade] que atenda ao Artigo 18 da DORA. Inclua os seguintes critérios de classificação da regulamentação e RTS: número de clientes/contrapartes financeiras afetados (forneça limiares específicos para nosso tipo de entidade), duração do incidente, abrangência geográfica do incidente, perdas de dados (confidencialidade, integridade, disponibilidade), criticidade dos serviços afetados (mapeados para nossa classificação de ativos de TIC), impacto econômico (perdas financeiras diretas e indiretas), avaliação de impacto reputacional. Para cada critério, defina: limiares quantitativos específicos que acionam a classificação como 'grave', metodologia de medição, fontes de dados para avaliação rápida e exemplos. Crie uma matriz de pontuação que permita a classificação dentro de 1-2 horas após a detecção do incidente. Inclua um fluxograma de decisão: se qualquer critério único atender ao limiar grave, o incidente é classificado como grave."
-
Crie o fluxograma de decisão de classificação:
"Projete um fluxograma de decisão passo a passo para classificação de incidentes conforme o Artigo 18 da DORA. O fluxograma deve ser utilizável por gestores de incidentes de plantão às 3h da manhã com informações limitadas. Comece com: detalhes iniciais do incidente (o que aconteceu, quando, o que foi afetado). Em seguida, avalie cada critério de incidente grave sequencialmente: clientes afetados (limiar: [X]), duração (limiar: [X] horas), impacto nos dados (qualquer violação de dados confirmada), serviços críticos afetados (qualquer serviço em nossa lista crítica), impacto econômico (estimado acima de [X] EUR). Se qualquer critério for atendido, classifique como GRAVE e acione o relatório de 4 horas. Se for limítrofe, escale para [função] para decisão de classificação. Se nenhum critério for atendido, classifique como não grave e siga o processo padrão de incidente. Forneça orientações para situações com informações incompletas."
Classificação sob incerteza: Durante as primeiras horas de um incidente, raramente se tem informações completas. A DORA espera que você classifique com base nas informações disponíveis e atualize se a classificação mudar. Projete seu processo para classificar de forma conservadora (em caso de dúvida, classifique como grave) e rebaixe posteriormente, se apropriado. Subnotificar é um risco regulatório maior do que supernotificar.
Acompanhamento de incidentes não graves
Embora apenas incidentes graves exijam notificação regulatória, a DORA exige que você acompanhe e analise todos os incidentes relacionados a TIC:
"Crie um procedimento de acompanhamento e análise de incidentes de TIC não graves para conformidade com a DORA. Inclua: requisitos de registro para todos os incidentes de TIC (modelo de registro de incidentes), metodologia de análise de tendências (identificar padrões que possam indicar problemas sistêmicos), critérios de escalonamento (quando o acúmulo de incidentes não graves sugere um problema grave), relatórios periódicos para a gestão (frequência, formato, conteúdo) e integração com o processo de melhoria contínua sob o Artigo 13. Forneça um modelo de relatório trimestral de tendências de incidentes."
Passo 3: Crie modelos de notificação regulatória (Artigos 19-20)
Modelo de notificação inicial (4 horas)
A notificação inicial deve ser submetida à sua autoridade competente dentro de 4 horas após classificar um incidente como grave. Construa modelos pré-preenchidos para cumprir este prazo:
-
Gere o modelo de notificação inicial:
"Crie um modelo de notificação inicial de incidente para o Artigo 19 da DORA (prazo de 4 horas). Pré-preencha com dados organizacionais permanentes. Inclua campos para: identificação da entidade relatora (nome, LEI, tipo de entidade, autoridade competente), identificador do incidente e data/hora da classificação, descrição do incidente (o que aconteceu, linha do tempo inicial), fundamentação da classificação (quais critérios graves são atendidos, com evidências), serviços afetados e avaliação inicial de impacto, número de clientes potencialmente afetados (estimativa se o exato não for conhecido), abrangência geográfica, ações iniciais de contenção tomadas, duração estimada se conhecida, detalhes de contato para acompanhamento e indicador de impacto transfronteiriço. Projete o modelo para que possa ser preenchido em menos de 60 minutos com as informações disponíveis no momento da classificação. Inclua notas de orientação para cada campo."
-
Gere o modelo de relatório intermediário (72 horas):
"Crie um modelo de relatório intermediário de incidente para o Artigo 19 da DORA (prazo de 72 horas). Inclua campos para: referência à notificação inicial, linha do tempo atualizada do incidente, avaliação de impacto atualizada (clientes afetados, impacto financeiro, impacto nos dados), análise de causa raiz (achados preliminares), medidas de contenção e mitigação implementadas, status de recuperação e linha do tempo estimada, quaisquer alterações na classificação do incidente, ações de comunicação tomadas (clientes, contrapartes, público), envolvimento de partes externas (autoridades policiais, provedores forenses), avaliação de risco atualizada e quaisquer ações supervisórias solicitadas. Inclua orientações sobre como fornecer uma análise de causa raiz significativa mesmo quando a investigação estiver em andamento."
-
Gere o modelo de relatório final (1 mês):
"Crie um modelo de relatório final de incidente para o Artigo 19 da DORA (prazo de 1 mês). Inclua seções abrangentes para: linha do tempo completa do incidente (da detecção à resolução), análise confirmada de causa raiz (técnica e organizacional), avaliação total de impacto (perdas financeiras quantificadas, clientes afetados, serviços interrompidos, dados comprometidos), descrição completa das ações de contenção, erradicação e recuperação, avaliação da eficácia dos controles existentes, plano de remediação (ações, responsáveis, prazos, status), lições aprendidas e melhorias no framework, notificação e decisões do órgão de gestão, conformidade com o cronograma de relatórios regulatórios e referências cruzadas a quaisquer incidentes relacionados. Este relatório deve ser adequado para revisão supervisória e servir como entrada para o processo de revisão pós-incidente sob o Artigo 13."
Dica profissional: Pré-preencha a seção de identificação organizacional de todos os três modelos com seus dados permanentes (nome da entidade, LEI, detalhes da autoridade competente, contato principal). Armazene esses modelos pré-preenchidos em um local acessível para sua equipe de resposta a incidentes. Durante um incidente real, cada minuto economizado em campos administrativos é um minuto ganho para análise substantiva.
Procedimentos de submissão
Estabeleça procedimentos claros para submeter relatórios à sua autoridade competente:
"Crie um procedimento de submissão de relatórios de incidentes para notificações regulatórias da DORA. Inclua: identificação de nossa autoridade competente e seu canal de relatório (portal, e-mail, API), autorização de submissão (quem pode autorizar a submissão e em que horário), lista de verificação de revisão de qualidade antes da submissão (integridade, precisão, consistência com relatórios anteriores), confirmação e rastreamento de submissão, procedimentos para submissão fora do horário comercial (para o prazo de 4 horas), métodos de submissão alternativos se o canal principal estiver indisponível, requisitos de manutenção de registros (cópias de todas as submissões com carimbos de data/hora) e procedimentos para lidar com feedback supervisório sob o Artigo 22. Aborde o cenário em que o próprio incidente afeta nossa capacidade de submeter relatórios."
Passo 4: Construa procedimentos de escalonamento e comunicação
Matriz de escalonamento interno
O escalonamento eficaz é crítico para cumprir os prazos rigorosos da DORA. Defina caminhos claros de escalonamento para cada cenário:
-
Gere a matriz de escalonamento:
"Crie uma matriz de escalonamento de incidentes de TIC para um [tipo de entidade] cobrindo os requisitos de relatório da DORA. Defina níveis de escalonamento: Nível 1 (SOC/Operações de TI): detecção e triagem inicial, Nível 2 (Equipe de Resposta a Incidentes): investigação e contenção, Nível 3 (CISO/CRO): decisão de classificação de incidente grave, Nível 4 (Órgão de Gestão): notificação de incidentes graves, aprovação de comunicação regulatória. Para cada nível, especifique: critérios de escalonamento (o que aciona o escalonamento para o próximo nível), cronograma de escalonamento (tempo máximo em cada nível antes do escalonamento), método de notificação e detalhes de contato, informações a serem fornecidas ao escalar e autoridade de decisão em cada nível. Inclua procedimentos de escalonamento fora do horário comercial e contatos de backup. Projete para garantir que a classificação possa ocorrer dentro de 2 horas após a detecção."
-
Crie procedimentos de notificação ao cliente:
"Desenvolva procedimentos de notificação ao cliente para incidentes graves de TIC sob a DORA. Inclua: critérios para quando os clientes devem ser notificados, timing da notificação em relação ao relatório regulatório, conteúdo da notificação (o que divulgar, o que reter durante a investigação), canais de comunicação (e-mail, portal, telefone para clientes críticos), modelos de notificação ao cliente para tipos comuns de incidentes (interrupção de serviço, violação de dados, degradação do sistema), cadência de comunicação de acompanhamento e requisitos de manutenção de registros. Aborde cenários em que o incidente afeta nossa capacidade de nos comunicarmos com os clientes."
O Artigo 19(3) da DORA exige que as entidades financeiras informem seus clientes sobre incidentes graves relacionados a TIC que afetem seus interesses financeiros. Você também deve comunicar sobre as medidas corretivas tomadas. Incorpore essa comunicação com o cliente em seu processo de resposta a incidentes desde o início.
Notificação ao órgão de gestão
O Artigo 5 exige que o órgão de gestão seja informado sobre incidentes de TIC. Defina como isso acontece durante incidentes:
"Crie um procedimento de notificação de incidentes ao órgão de gestão para conformidade com o Artigo 5 da DORA. Inclua: gatilhos de notificação (todos os incidentes graves, incidentes não graves significativos), cronograma de notificação (dentro de [X] horas após a classificação), formato de notificação (modelo de briefing estruturado), conteúdo (resumo do incidente, avaliação de impacto, ações de resposta, status de relatório regulatório, impacto ao cliente, risco de mídia), pontos de decisão que requerem entrada do órgão de gestão (comunicações públicas, compensação ao cliente, engajamento regulatório), cadência de relatórios de acompanhamento durante incidentes em andamento e apresentação de briefing pós-incidente e lições aprendidas. Forneça o modelo de briefing de incidente para o órgão de gestão."
Passo 5: Integre com a gestão de incidentes existente
Mapeando os requisitos da DORA para seus processos atuais
A maioria das entidades financeiras já possui processos de gestão de incidentes. Use o ISMS Copilot para integrar os requisitos da DORA ao seu framework existente, em vez de criar processos paralelos:
"Atualmente, usamos processos de gestão de incidentes [ITIL/NIST/personalizados] com [descreva as ferramentas atuais: ServiceNow, Jira, PagerDuty, etc.]. Mapeie os requisitos dos Artigos 17-23 da DORA para nosso processo existente. Identifique: onde nosso processo atual já atende à DORA (detecção, triagem, contenção, recuperação), onde precisamos adicionar etapas específicas da DORA (classificação de incidentes graves, relatório regulatório, notificação ao cliente), modificações de processo necessárias (compressão de cronograma, aprimoramentos de escalonamento), mudanças de ferramentas necessárias (automação de classificação, geração de relatórios, rastreamento de submissão) e atualizações de documentação necessárias. Forneça uma análise de lacunas com ações específicas de remediação."
Automatizando a classificação e o relatório
Dado o prazo de 4 horas, considere oportunidades de automação:
"Identifique oportunidades para automatizar a classificação e o relatório de incidentes DORA para um [tipo de entidade]. Considere: coleta automatizada de pontos de dados de classificação (número de clientes afetados a partir de sistemas de monitoramento, métricas de disponibilidade de serviço, impactos no volume de transações), pré-preenchimento automatizado de modelos de relatório a partir de ferramentas de gestão de incidentes, cálculo automatizado de limiares de critérios de incidentes graves, automação de fluxo de trabalho para escalonamento e notificações, integração entre SIEM/plataforma de incidentes e fluxo de trabalho de relatório, rastreamento automatizado de prazos e alertas de lembrete e compilação automatizada de métricas de incidentes para análise de tendências. Forneça recomendações de implementação priorizadas pelo impacto no prazo de 4 horas."
Dica profissional: Mesmo que você não consiga automatizar totalmente a classificação, automatize a coleta de dados que informam as decisões de classificação. Se seus sistemas puderem relatar automaticamente quantos clientes são afetados, quais serviços estão degradados e por quanto tempo, sua decisão de classificação se tornará muito mais rápida e defensável perante os reguladores.
Passo 6: Procedimentos de análise de causa raiz
Metodologia estruturada de análise de causa raiz
A DORA exige análise de causa raiz como parte dos relatórios intermediário (72 horas) e final (1 mês). Estabeleça uma metodologia padronizada:
-
Gere a metodologia de RCA:
"Crie uma metodologia de análise de causa raiz (RCA) para relatórios de incidentes de TIC da DORA. Inclua: critérios e timing de iniciação da RCA (começar dentro de 24 horas após a classificação de incidente grave), métodos de investigação (5 Porquês, espinha de peixe/Ishikawa, análise de árvore de falhas, análise de linha do tempo), procedimentos de coleta e preservação de evidências, etapas de investigação técnica (análise de logs, forense, exame de sistema), etapas de investigação organizacional (revisão de processos, conformidade com políticas, adequação de treinamento), categorias de causa raiz (falha técnica, erro humano, lacuna de processo, falha de terceiros, ataque externo, falha de design), processo de RCA preliminar para o relatório intermediário de 72 horas (estruturado mesmo com informações incompletas), processo de RCA abrangente para o relatório final de 1 mês, revisão de qualidade dos achados da RCA antes da submissão e ligação entre causas raiz e ações de remediação. Forneça um modelo de relatório de RCA com exemplos."
-
Crie procedimentos de acompanhamento de remediação:
"Desenvolva um procedimento de acompanhamento de remediação pós-incidente para conformidade com a DORA. Inclua: como as ações de remediação são identificadas a partir dos achados da RCA, metodologia de priorização de ações (crítica, alta, média com base no risco), atribuição de ações (responsável, prazo, recursos), acompanhamento e relatório de progresso, supervisão do órgão de gestão sobre o progresso da remediação, verificação da eficácia da remediação, critérios de encerramento para ações de remediação e integração com o registro de risco de TIC (atualização de avaliações de risco com base nos achados do incidente). Forneça um modelo de registro de acompanhamento de remediação."
Passo 7: Notificação de ameaças cibernéticas (Artigo 23)
Relatório voluntário de ameaças
O Artigo 23 incentiva as entidades financeiras a notificarem as autoridades competentes sobre ameaças cibernéticas significativas, mesmo que ainda não tenham resultado em incidentes. Estabeleça procedimentos para este relatório voluntário:
"Crie um procedimento de notificação de ameaças cibernéticas significativas para o Artigo 23 da DORA. Inclua: critérios para o que constitui uma 'ameaça cibernética significativa' que justifica notificação voluntária (ataques direcionados detectados, mas contidos, inteligência sobre ameaças iminentes, vulnerabilidades de dia zero que afetam sistemas críticos, padrões de ameaças em todo o setor), processo interno de avaliação e decisão (quem decide se notifica), modelo de notificação para ameaças cibernéticas (diferente dos relatórios de incidentes), expectativas de timing (não obrigatório, mas deve ser rápido), considerações de confidencialidade e limitações de compartilhamento de informações e benefícios do relatório voluntário (boa vontade supervisória, proteção setorial, compartilhamento de inteligência). Forneça critérios de decisão e um modelo de notificação."
Passo 8: Teste sua capacidade de relatório de incidentes
Exercícios de mesa e simulações
Seus procedimentos de classificação e relatório de incidentes devem ser testados antes que um incidente real ocorra. Use o ISMS Copilot para projetar exercícios realistas:
-
Projete cenários de exercícios de mesa:
"Projete três cenários de exercícios de mesa para testar nossos procedimentos de classificação e relatório de incidentes da DORA. Cada cenário deve: ser realista para um [tipo de entidade], se desenrolar em várias fases (detecção inicial, escalonamento, contenção, relatório), testar a decisão de classificação de incidente grave, testar o processo de notificação inicial de 4 horas de ponta a ponta, incluir complicações (informações incompletas, detecção fora do horário comercial, múltiplos problemas simultâneos), testar gatilhos de comunicação com o cliente e exigir notificação ao órgão de gestão. Os cenários devem abranger: (1) ataque de ransomware afetando sistemas críticos de banco/pagamento, (2) interrupção do provedor de nuvem afetando múltiplos serviços, (3) violação de dados descoberta por notificação externa. Para cada cenário, forneça um guia do facilitador do exercício com linha do tempo de injeções, ações esperadas dos participantes e critérios de avaliação."
-
Crie um framework de avaliação de exercícios:
"Crie um framework de avaliação para exercícios de mesa de relatório de incidentes da DORA. Avalie: tempo da detecção à classificação (meta abaixo de 2 horas), tempo da classificação à submissão da notificação inicial (meta abaixo de 4 horas), precisão da decisão de classificação, completude da notificação inicial, qualidade do escalonamento e comunicação, eficácia da notificação ao órgão de gestão, adequação da comunicação com o cliente, qualidade da documentação e coordenação da equipe. Forneça uma rubrica de pontuação e um modelo de relatório pós-exercício."
Expectativa de auditoria: As autoridades competentes esperam evidências de que seus procedimentos de relatório de incidentes foram testados. Realize exercícios de mesa pelo menos anualmente (com mais frequência no primeiro ano de implementação) e documente resultados, lições aprendidas e melhorias feitas. Essa evidência demonstra aos reguladores que sua capacidade de relatório de 4 horas é genuína, não teórica.
Próximos passos
Agora você tem uma capacidade abrangente de relatório de incidentes DORA:
- Processo de gestão de incidentes integrado às capacidades de detecção
- Matriz de classificação com limiares quantitativos para incidentes graves
- Modelos de notificação regulatória em três etapas (4 horas, 72 horas, 1 mês)
- Matriz de escalonamento com autoridades de decisão e cronogramas claros
- Metodologia de análise de causa raiz com acompanhamento de remediação
- Procedimentos de notificação de ameaças cibernéticas
- Procedimentos testados por meio de exercícios de mesa
Continue com os próximos guias desta série DORA:
- How to plan DORA resilience testing using AI -- Projete seu programa de testes, incluindo cenários que validem suas capacidades de resposta e relatório de incidentes
- How to manage DORA third-party ICT risk using AI -- Garanta que seus provedores terceirizados de TIC possam apoiar suas obrigações de relatório de incidentes com cláusulas de notificação e SLAs adequados
Para a configuração fundamental, consulte How to get started with DORA implementation using AI. Para o framework de risco de TIC que sustenta a gestão de incidentes, consulte How to build a DORA ICT risk management framework using AI.
Para prompts prontos para uso, consulte a DORA Compliance Prompt Library. Para a visão geral regulatória completa, consulte o DORA Compliance Guide for Financial Entities.
Obtendo ajuda
Para suporte adicional na implementação de relatórios de incidentes DORA:
- Pergunte ao ISMS Copilot: Use seu espaço de trabalho DORA para gerar orientações de classificação específicas para cenários e personalizar modelos de relatório para o tipo de sua entidade
- Envie procedimentos existentes: Obtenha uma análise de lacunas direcionada enviando seu plano atual de resposta a incidentes para comparação com os Artigos 17-23 da DORA
- Simule relatórios: Use o ISMS Copilot para percorrer cenários de incidentes simulados e praticar o preenchimento de modelos de notificação sob pressão de tempo
- Valide saídas: Revise todos os critérios de classificação e modelos de relatório em relação ao texto regulatório da DORA e aos Padrões Técnicos Regulatórios relevantes antes da adoção formal
Construa sua capacidade de relatório de incidentes hoje. Abra seu espaço de trabalho DORA em chat.ismscopilot.com e comece com sua matriz de classificação. Quando o próximo incidente de TIC ocorrer, você estará pronto para classificar, relatar e responder dentro dos prazos rigorosos da DORA.