Resiliência que o supervisor consegue ler
O DORA aplica-se desde 17 de janeiro de 2025 aos bancos, instituições de pagamento, empresas de investimento, seguradoras e às restantes entidades financeiras que enumera. Pede evidência e não políticas: um inventário dos ativos de TIC, sistemas testados e um registo de informações sobre todos os terceiros prestadores de serviços de TIC. Respondemos a essas obrigações com uma auditoria de código fonte, quatro produtos e equipas de engenharia que constroem a pensar no registo.
A diferença face aos regimes anteriores está na forma da resposta. Uma política diz o que deveria acontecer; o DORA pergunta o que aconteceu, em que sistema, testado quando e por quem. Tudo nesta página existe para produzir esse registo.
Artigo a artigo
Regulamento (UE) 2022/2554. As disposições sobre as quais um supervisor técnico pergunta primeiro, e o que da nossa parte responde a cada uma.
| Disposição | O que o DORA exige | O que trazemos |
|---|---|---|
| Art. 8.ºIdentificação | Identificar e documentar todos os ativos de TIC e as dependências entre eles, e manter esse inventário atualizado. | O Ibex descobre os hosts dos seus segmentos de rede, incluindo aqueles a que nenhum agente na cloud chega, e mantém um registo por equipamento, comparado com a sua linha de base. O Buteo mantém o inventário do lado de fora: os subdomínios, serviços e certificados que os seus domínios mostram à internet. |
| Art. 9.ºProteção e prevenção | Cifragem, aplicação de patches, controlo de acessos e configuração segura, com a segurança dos sistemas de TIC monitorizada em permanência. | O Ibex verifica o que as suas bases de dados permitem face a um conjunto de regras, e a auditoria de código lê se as regras de desenvolvimento seguro se cumpriram. Ambos saem do appliance como ficheiros que o auditor pode guardar: as falhas em SARIF e o PDF da auditoria. |
| Art. 24.º, n.º 6Testes, pelo menos anuais | Todos os sistemas de TIC que apoiam funções críticas ou importantes são testados pelo menos uma vez por ano. | O Goshawk corre a auditoria de código a pedido, pelo que o teste anual é uma execução agendada e não um procedimento de aquisição. |
| Art. 25.º, n.º 1Revisão do código fonte | Um programa de testes de resiliência operacional digital que inclua revisões do código fonte quando tal for exequível. | A Auditoria de segurança: uma revisão manual, pontuada com CVSS v4.0, numa forma que o programa de testes pode arquivar. |
| Art. 28.ºRisco de terceiros | Um registo de informações sobre todos os terceiros prestadores de serviços de TIC, e uma avaliação do risco que cada um comporta. | Uma auditoria à aplicação que um fornecedor entrega, antes da aceitação ou da renovação, é evidência para essa avaliação que não depende da palavra do fornecedor. |
| Art. 30.ºDireitos de auditoria ao longo da cadeia | Direitos contratuais de acesso, inspeção e auditoria sobre os prestadores que apoiam funções críticas ou importantes, e sobre os seus subcontratantes. | Um modelo na cloud para o qual escala pedidos é um prestador que não pode auditar. O Marmot decide, pedido a pedido, o que lhe pode chegar, e o seu registo de decisões concilia-se com a sua própria firewall. |
A página da Auditoria de segurança liga a mesma revisão à NIS2 e ao seu regulamento de execução, para as obrigações que uma entidade financeira tem fora do DORA. Para Portugal, quem fiscaliza, os prazos de comunicação de incidentes, as coimas da Lei n.º 73/2025 e uma autoavaliação estão em DORA em Portugal.
Onde costumamos ser chamados
Inventários de ativos de TIC e evidência de resiliência para a supervisão do DORA
Portais de crédito digital, tesouraria e gestão de património com a conformidade integrada
Modernização de pagamentos e ligação ao Open Banking
Quando a resposta é software que construímos
Algumas obrigações cumprem-se com um produto e outras com um portal, uma API ou um fluxo de trabalho que ainda não existe. Para essas integramos equipas de produto, design e engenharia com a sua equipa, sobre o sistema bancário que já tem em funcionamento, em parceria com o risco, a conformidade e a segurança.
Sprints de co-design com o risco, a conformidade e as operações, para que a evidência que o DORA pede seja desenhada de raiz e não reconstruída mais tarde
Portais, APIs e ferramentas de fluxo de trabalho à medida, sobre os seus sistemas bancários centrais ou de pagamentos
Ligação ao Open Banking e à PSD2, reaproveitada onde se aplica
Desenvolvimento seguro que um auditor consegue acompanhar: documentação, testes e um SDLC que deixa o registo que o quadro de gestão do risco associado às TIC espera
Equipas de longo prazo que ficam com o produto depois do lançamento, porque a resiliência mede-se depois da entrada em produção
Telemetria integrada, para que a adoção e os incidentes sejam medidos e não adivinhados
Os produtos por trás do quadro
O Ibex para o inventário e a postura do lado de dentro, o Buteo para o que os seus domínios mostram à internet, o Goshawk para o código e o Marmot para a IA que não se pode tornar num terceiro prestador de serviços de TIC.
Ibex
Segurança para as redes onde a cloud não chega
Gestão da superfície de ataque em air-gapped (rede isolada): rede, código, IA e bases de dados avaliados a partir de um appliance selado dentro do seu perímetro, com cada falha ligada ao host onde corre.
Saber mais sobre Ibex
Buteo
Auditoria da superfície de ataque externa
A vista de fora do seu domínio, como serviço: postura de DNS e de email, TLS, cabeçalhos, subdomínios e portas, com pontuação e comparação entre análises.
Saber mais sobre Buteo
Goshawk
Só sai o que resiste à refutação
Auditorias de segurança aos seus repositórios, como aplicação: análise automática com os limites declarados por escrito, e um nível completo com verificação humana sénior.
Saber mais sobre Goshawk
Marmot
IA soberana, com uma porta de controlo
IA nas suas instalações, com uma porta que decide, pedido a pedido, o que pode chegar a um modelo na cloud e o que nunca sai do edifício.
Saber mais sobre Marmot