Software · DORA
Um software DORA deve comprovar que a sua instituição cumpre o regulamento relativo à resiliência operacional digital: gestão do risco de TIC sob a responsabilidade do órgão de administração, gestão e notificação de incidentes, testes de resiliência e gestão dos terceiros prestadores de serviços de TIC, incluindo o registo de informações. Esta página mostra o que um software deve fazer para isso, a que deve prestar atenção na escolha e como o Sightadel o concretiza.
Ponto de partida
O DORA aplica-se desde janeiro de 2025 às entidades financeiras em toda a UE. O regulamento assenta em cinco pilares: gestão do risco de TIC, gestão e notificação de incidentes relacionados com as TIC, testes de resiliência operacional digital, gestão do risco de terceiros no domínio das TIC e partilha voluntária de informações sobre ameaças. As normas técnicas das autoridades europeias de supervisão regulam os pormenores; na Alemanha, a supervisão cabe à autoridade federal alemã de supervisão financeira (BaFin). Não existe um certificado DORA.
Para um software, são sobretudo quatro os requisitos determinantes. O órgão de administração aprova o quadro de gestão do risco de TIC e assume a responsabilidade (art. 5.º–6.º). Os incidentes são classificados segundo critérios uniformes, os graves são notificados, a notificação inicial o mais tardar 24 horas após o conhecimento (art. 17.º–19.º). Um programa de testes baseado no risco aplica-se a todos; determinadas entidades realizam adicionalmente, pelo menos de três em três anos, testes de penetração baseados em ameaças (art. 24.º–27.º). E o registo de informações abrange todos os contratos com prestadores de serviços de TIC (art. 28.º).
O registo é geralmente a parte mais trabalhosa, porque os dados não estão completos em nenhuma pasta de contratos. Um software DORA deve fazê-lo surgir da manutenção corrente dos prestadores de serviços, e não de uma recolha apressada antes da data de referência. Decisões como o apetite pelo risco, a classificação de funções críticas ou importantes e as estratégias de saída continuam a caber ao órgão de administração.
Porquê agora
A BaFin solicita o registo de informações uma vez por ano, com referência a uma data. Quem só o atualiza pouco antes volta a procurar tudo do início todos os anos.
Pergunta-se pelo quadro, pela sua revisão anual, pelos resultados dos testes e pelo tratamento das constatações. Contam comprovativos com data, não declarações de intenções.
Antes da celebração do contrato, são necessárias a avaliação do risco e a verificação do conteúdo contratual segundo o art. 30.º. Depois, o prestador de serviços tem de entrar no registo.
A primeira vaga decorreu como projeto, com folhas de cálculo e pastas na rede. Para a operação corrente, isso raramente basta.
Frameworks relevantes
Resumido por palavras nossas, não constitui aconselhamento jurídico. Prevalece o texto original na versão em vigor.
Para entidades financeiras na UE. No Sightadel, 50 requisitos com referência ao artigo e evidência esperada. Para colmatar as lacunas existentes passam tipicamente seis a doze meses. Para determinadas entidades mais pequenas existe um quadro simplificado.
Ver framework →A gestão do risco de TIC, o controlo de acessos, as cópias de segurança e o tratamento de incidentes assentam nas mesmas bases. O registo de informações não tem equivalente na ISO 27001.
Ver framework →Para as entidades financeiras, o DORA prevalece. Muitas medidas coincidem; os prazos de notificação diferem no ponto de partida: o DORA parte da classificação, a NIS2 do conhecimento do incidente.
Ver framework →Um relatório de atestação C5 de um fornecedor de cloud é uma evidência valiosa na avaliação desse prestador de serviços. Não substitui a avaliação de risco própria.
Ver framework →As medidas técnicas e os acordos de subcontratação recorrem aos mesmos dados dos prestadores de serviços. Um incidente pode desencadear várias obrigações de notificação.
Ver framework →Ordem recomendada
Esclarecer que obrigações se aplicam, se o quadro simplificado é uma opção e que funções são críticas ou importantes.
Percorrer de forma guiada os 50 requisitos, associar as evidências existentes do SGSI, da gestão de continuidade e das compras.
Registar os prestadores de serviços, os contratos, as funções suportadas e os subcontratantes. As listas existentes entram por importação do Excel.
Definir critérios de classificação, responsabilidades e vias de notificação e simulá-los uma vez.
Planos de ação com responsáveis e prazos. As adaptações contratuais são muitas vezes as mais demoradas, porque a outra parte tem de colaborar.
Executar o programa de testes, rever o quadro anualmente, manter o registo atualizado. Depois, estes passos repetem-se como ciclo.
Escolha
Muitas ferramentas cobrem pilares isolados, por exemplo só o registo ou só a gestão de incidentes. Verifique se o software mantém todas as obrigações juntas e se se adequa à sua dimensão.
Cada requisito deve remeter para o artigo do regulamento e indicar a evidência esperada. Assim, as perguntas da auditoria interna podem ser associadas diretamente.
Os prestadores de serviços, os contratos, as funções suportadas e a criticidade devem ser mantidos num só sítio. O registo não pode ser um projeto separado em função da data de referência.
Quem também notifica ao abrigo da NIS2 ou do RGPD precisa de uma separação clara dos pontos de partida. O DORA parte da classificação como grave, a NIS2 do conhecimento do incidente.
Os testes devem ser planeados como datas recorrentes e as constatações acompanhadas com prazo e responsável. O teste baseado em ameaças propriamente dito é realizado por testadores especializados.
A aprovação do quadro, as deliberações e as formações da gestão de topo devem estar arquivadas com data. Estão no início de qualquer verificação.
Uma instituição pequena tem a mesma obrigação, mas não precisa do mesmo aparato que um grande banco. Verifique se o software pode ser utilizado sem uma longa implementação.
Como o Sightadel ajuda
50 requisitos com referência ao artigo e evidência esperada, cada um como pergunta com explicação. As evidências da ISO 27001 podem ser reutilizadas diretamente.
Saber mais →Prestadores de serviços com funções suportadas, criticidade, contratos e evidências com data de validade. As reavaliações chegam como lembrete. Assim, o registo de informações cresce a partir da manutenção corrente.
Saber mais →Relatórios de testes, testes de recuperação e deliberações com versão e data de validade. Se uma evidência expirar, aparece como tarefa antes de a auditoria interna dar por ela.
Saber mais →As constatações de testes, verificações e cláusulas contratuais em falta tornam-se medidas com responsável e prazo. O registo de atividade mostra quem fez o quê e quando.
Saber mais →Sincronização regular com sistemas como SAP, Microsoft Dynamics, Microsoft Azure ou Jira. Os ativos, as evidências e as tarefas vêm dos sistemas onde já são mantidos.
Saber mais →Esforço e duração
Os intervalos refletem a experiência e não constituem um compromisso. Geralmente, é o registo de informações e as adaptações contratuais que determinam o ritmo, não o software.
O que licencia · tipicamente Professional
Uma instituição típica gere o DORA juntamente com a ISO 27001 como base na edição Professional. Com muitos prestadores de serviços de TIC ou várias sociedades, a edição Enterprise é a escolha adequada. Se a ISO 27001 estiver incluída, o DORA custa permanentemente menos.
Licença por framework, duração mínima de um ano, pagamento mensal ou anual. Todos os preços, descontos e uma calculadora estão na página de preços. Os custos de um organismo de certificação ou de auditoria acrescem à parte.
Perguntas e respostas
Mais nas nossas perguntas frequentes ou diretamente através do nosso formulário de contacto.
O regulamento não prescreve nenhum software. Exige um quadro documentado, um registo de informações completo, um tratamento de incidentes rastreável e um programa de testes. Com poucos prestadores de serviços, isso é possível com folhas de cálculo. Com muitos contratos, vários participantes e apresentação anual, compensa ter um sistema.
Para a primeira apresentação, muitas instituições utilizaram folhas de cálculo. Cada alteração contratual, cada novo prestador de serviços e cada teste têm então de ser acrescentados manualmente. As listas existentes podem ser importadas para o Sightadel.
O Sightadel é licenciado por framework e edição, anualmente. Os valores atuais estão na página de preços. Se a ISO 27001 já estiver licenciada, o DORA custa permanentemente menos. Pode experimentar grátis durante 14 dias, sem dados de pagamento.
Não. O Sightadel guia através dos requisitos e regista o ponto de situação. O consultor é escolhido na rede de parceiros na aplicação, ou traz o seu. As verificações pela auditoria interna, pelo revisor oficial de contas e pela supervisão mantêm-se inalteradas. O Sightadel não certifica e não recebe qualquer comissão.
Aprova o quadro de gestão do risco de TIC, define o apetite pelo risco, delibera sobre a classificação das funções críticas ou importantes e disponibiliza os recursos. O Sightadel fornece rascunhos e regista as deliberações com data. As decisões são tomadas pelo próprio órgão.
Não. O TLPT é realizado por testadores especializados. O Sightadel regista o planeamento, o resultado e o tratamento das constatações. Mais informações sobre os requisitos na página sobre o DORA.
O Sightadel é desenvolvido e operado na Alemanha.
14 dias, acesso completo, sem dados de pagamento. Tudo o que configurar mantém-se no plano pago.
