Segurança de SaaS sob a DORA

O Digital Operational Resilience Act (Regulamento (UE) 2022/2554) é um conjunto único de regras para a resiliência operacional digital do setor financeiro da UE. Aplica-se diretamente em todos os Estados-membros desde 17 de janeiro de 2025. Abrange bancos, seguradoras, empresas de investimento, instituições de pagamento e de moeda eletrônica e outras entidades financeiras.

O regulamento assenta em cinco pilares: gestão de risco de ICT, gestão e comunicação de incidentes de ICT, testes de resiliência operacional digital, gestão de risco de terceiros de ICT e compartilhamento de informações. O SaaS se enquadra sobretudo no pilar de risco de terceiros.

Quase todo aplicativo SaaS usado por uma instituição financeira, como suítes de colaboração, CRM, RH, análise de dados ou gestão de documentos, é um serviço de ICT prestado por terceiro. Assim, o contrato conta como acordo com terceiro de ICT, segundo o capítulo da DORA sobre risco de terceiros.

Provedores designados como prestadores terceiros críticos de serviços de ICT também são supervisionados diretamente pelas Autoridades Europeias de Supervisão. Essa supervisão não transfere a responsabilidade: perante o próprio supervisor, a instituição financeira continua respondendo pela resiliência das funções que o SaaS apoia.

A DORA exige que cada instituição financeira mantenha um registro de informações com todos os seus acordos com terceiros de ICT, e todo contrato de SaaS deve constar nele. O registro traz a identidade do provedor, a descrição dos serviços, se apoiam funções críticas ou importantes, a cadeia de subcontratados, as localizações dos dados e os direitos de rescisão.

O registro é encaminhado às autoridades competentes, que informam as Autoridades Europeias de Supervisão. Registros incompletos de SaaS aparecem, assim, na revisão supervisora e não ficam como lacuna interna. Um registro de ativos de TI preciso é o ponto de partida prático.

A avaliação é um dever ao longo de todo o ciclo de vida, e não uma formalidade de compra. Antes de depender de um serviço SaaS, a instituição deve avaliar a capacidade técnica do provedor, suas práticas de segurança, a qualidade do suporte e a solidez financeira, e repetir a revisão quando as circunstâncias mudam.

A concentração recebe atenção específica. Quando muitas instituições dependem das mesmas poucas plataformas SaaS, a falha de um único provedor vira evento do setor inteiro, por isso o registro também mostra o quanto cada serviço é realmente substituível.

A DORA fixa o conteúdo mínimo dos contratos de serviços de ICT. Na prática, um acordo de SaaS precisa conter pelo menos estas disposições:

A DORA padroniza a classificação e a notificação de incidentes graves relacionados a ICT. Um incidente que começa em um provedor de SaaS continua sendo incidente da instituição. Ela precisa detectar que uma dependência foi degradada e avaliar o impacto sobre as próprias funções.

Nem todo incidente grave é uma violação de dados. A queda de um provedor que para um serviço crítico também pode ser notificável. Os relatórios inicial, intermediário e final devem ser enviados nos prazos definidos, e para isso é preciso saber antecipadamente quais funções dependem de quais serviços.

Os testes de resiliência precisam incluir a dimensão dos terceiros. Os programas de teste, incluindo os testes de penetração guiados por ameaças (TLPT) para entidades designadas pela autoridade, devem considerar cenários em que um serviço de SaaS fica indisponível, degradado ou comprometido. Devem verificar se a recuperação e as estratégias de saída funcionam sob pressão, e não apenas existem na documentação.

Nem todo dever se aplica a todo serviço do mesmo modo. Obrigações desse tipo costumam ser conduzidas em um processo de gestão de conformidade, e o status abaixo depende do escopo.

Nenhum controle isolado cobre todo o quadro de SaaS. A revisão de contratos verifica o papel, enquanto o inventário e os registros de atividade mostram o que é de fato usado. Serviços adotados sem aprovação, o núcleo do Shadow IT, ficam na lacuna entre eles.

O regulamento define as obrigações, mas a prática começa por saber quais serviços SaaS a organização de fato usa. Serviços adotados por equipes isoladas nunca entram no registro e nunca são avaliados, e mesmo assim transportam os mesmos fluxos de dados que os aprovados.

Nenhum dos controles abaixo é citado nominalmente no regulamento. Sem eles, porém, as obrigações que o regulamento cita dificilmente são cumpridas. Definir quais dados podem chegar a cada serviço é o papel da prevenção de perda de dados.

1. 1

   Comece pelo inventário

   Registre cada aplicativo SaaS em uso, inclusive os que os funcionários adotam por conta própria.

2. 2

   Classifique os dados

   Defina quais dados podem chegar a cada serviço.

3. 3

   Cubra os canais de entrada

   Aplique prevenção de perda de dados a envios pelo navegador, clientes de sincronização e e-mail, para que os dados regulados cheguem apenas aos serviços do registro.

4. 4

   Registre a atividade dos usuários

   Mantenha uma trilha de evidências nos aplicativos SaaS e ao redor deles, para a classificação de incidentes e as perguntas dos supervisores.

Comece pelos dados cuja exposição causaria mais prejuízo e depois mapeie os serviços que podem recebê-los. Uma política de classificação de dados dá a todos os contratos e controles o mesmo ponto de referência.

Leitura adicional: O conceito de "Zero Trust".