SLA e Gestão de Riscos: O Papel do DPO na Contratação de Sistemas

Ao contratar um sistema para nossa empresa, damos por certo que ele funcionará corretamente, de forma ininterrupta e sem falhas. No entanto, vemos que na prática não é bem assim. Sistemas apresentam problemas e indisponibilidades, é normal. Mas, o que ocorre se essas falhas são constantes, ou se o sistema ficar fora do ar? E pior, e se essa indisponibilidade ocorre em horário de pico da operação?

Quando um software ou serviço crítico fica fora do ar, os impactos vão muito além do simples inconveniente: podem gerar paralisação operacional, prejuízos financeiros, riscos jurídicos e até violações da LGPD. É nesse contexto que entra o SLA — Service Level Agreement, ou Acordo de Nível de Serviço. Vamos falar sobre ele.

O que é SLA e Por que ele Importa?

O SLA é o contrato que define os parâmetros mínimos de desempenho e disponibilidade de um sistema fornecido por terceiros. Um SLA bem estruturado não protege apenas a empresa juridicamente: ele garante que operações essenciais possam continuar mesmo diante de falhas externas.

Um SLA bem estruturado deve prever ao menos as seguintes questões:

• Classificação de severidade dos incidentes (baixa, média, alta e crítica): O que é "crítico" para o negócio?

• Qual porcentual de tempo o sistema deve estar operativo?

• Quanto tempo o fornecedor tem para atuar em caso de falhas?

• Quanto tempo o fornecedor tem para restaurar o sistema após uma interrupção? (RTO)

• Quanto do meu histórico de dados posso perder, medido em tempo? (RPO)

• Qual são os horários de atendimento para suporte e os canais de contato?

• Quais são as consequências para o fornecedor em caso de descumprimento (multas, créditos ou rescisão contratual)?

Sem SLA bem definido, a empresa contratante fica, na prática, sem instrumentos jurídicos eficazes quando o fornecedor demora a responder incidentes, mantém o sistema fora do ar, falha em restaurar dados ou presta suporte incompatível com a criticidade da operação.

Vamos analisar com maior profundidade alguns desses pontos:

Níveis de Criticidade das Falhas

Um dos elementos mais importantes — e frequentemente negligenciados — de um SLA é a definição dos níveis de criticidade das falhas. Nem toda indisponibilidade tem o mesmo impacto para o negócio, e é essa classificação que permite estabelecer respostas proporcionais à gravidade do incidente.

Em geral, os incidentes são organizados em níveis de criticidade como:

• Baixa: falhas que não interrompem a operação principal, como erros visuais ou funcionalidades secundárias indisponíveis. Exemplo: O sistema está demorando para gerar relatórios ou apresenta uma falha na formatação das cores dos gráficos.

• Média: problemas que afetam parte dos usuários ou reduzem a eficiência operacional, mas permitem continuidade parcial das atividades. Exemplo: O sistema de chat está fora do ar, mas os clientes ainda conseguem ser atendidos por e-mail e telefone.

• Alta: indisponibilidades que comprometem processos essenciais do negócio. Exemplo: No dia do fechamento da folha de pagamento, o módulo de cálculo de impostos apresenta erro crítico.

• Crítica: paralisação total do sistema ou risco relevante à operação, segurança da informação ou atendimento ao cliente. Exemplo: O sistema de checkout de um e-commerce para de processar transações.

Uma falha considerada crítica deve ter atendimento imediato, enquanto falhas menores podem admitir prazos mais extensos. Para cada nível de criticidade, o contrato deve estabelecer um tempo máximo de resposta (quanto tempo o fornecedor tem para iniciar o atendimento); e um tempo máximo de resolução (quanto tempo o fornecedor tem para restabelecer o serviço).

Sem essa vinculação clara entre criticidade e prazos de resolução, todos os incidentes passam a ser tratados da mesma forma — e a empresa perde capacidade de exigir prioridade justamente quando mais precisa.

Índice de Disponibilidade

O índice de disponibilidade é a porcentagem de tempo em que um sistema permanece funcional dentro de um período determinado (mensal ou anual). Ele representa a promessa quantificável de que um serviço estará operacional e acessível quando o usuário precisar. Mais do que um número, ele é o indicador de confiabilidade da infraestrutura de um fornecedor.

No mercado, encontramos softwares que prometem diferentes índices de disponibilidade. Normalmente, entre 95% e 99,999%. A diferença parece pequena no papel, mas o impacto real é drástico:

• 95% de disponibilidade: Permite que o sistema fique fora do ar por até 36 horas mensais (ou 18 dias por ano). Para uma empresa que opera em horário comercial, pode significar quase dois dias inteiros de operação paralisada todo mês.

• 99,999% de disponibilidade: o sistema pode ficar fora do ar apenas 5,26 minutos por ano.

O índice deve ser maior quanto mais crítico é o programa. Sistemas internos ou SaaS B2B admitem uma disponibilidade menor do que um sistema bancário, um e-commerce ou um sistema de gestão de infraestruturas críticas, como telecomunicações ou serviços de urgência.

Para que o índice seja justo, o cálculo de disponibilidade não deve contabilizar todo e qualquer tempo de inatividade, mas apenas aqueles que dependem exclusivamente do fornecedor. Ficam fora desse cálculo as manutenções programadas, falhas em serviços externos ao software, desastres naturais, mau uso ou alterações indevidas feitas pelo próprio cliente no sistema.

Contratar um sistema com um SLA de disponibilidade baixo (como 95%) pode gerar um efeito dominó de prejuízos para a empresa:

• Perda de Produtividade: Funcionários ociosos enquanto aguardam o sistema voltar representam um custo direto de folha de pagamento sem retorno.

• Danos à Reputação: Se o sistema for voltado ao cliente final (como um e-commerce ou portal de serviços), a indisponibilidade gera frustração e migração para a concorrência.

• Custo de Oportunidade: Vendas que deixam de ser feitas e leads que não são capturados durante o período de queda.

• Insegurança Operacional: A gestão perde a confiança nos dados e na ferramenta, muitas vezes recorrendo a "processos paralelos" em planilhas, o que aumenta o risco de erro humano.

Ao negociar um SLA, é vital alinhar a criticidade do processo de negócio ao índice contratado. Nem todo sistema precisa de cinco noves, mas aceitar menos de 99% exige um plano de contingência sólido para os dias em que a ferramenta inevitavelmente falhar.

RTO, RPO e Suporte Técnico

O RPO (Recovery Point Objective) e o RTO (Recovery Time Objective) são conceitos desconhecidos para a maioria das pessoas, mas têm impacto direto na continuidade do negócio.

O RPO define a quantidade aceitável de dados que a empresa pode perder, medida em tempo. Ele determina a frequência com que você deve fazer seus backups. Já o RTO é o tempo máximo permitido para restaurar o sistema após a falha. É a janela de tempo entre o momento em que o sistema cai e o momento em que ele volta a estar disponível para os usuários.

Vamos ver um exemplo prático:

Considere uma empresa que contratou um sistema de gestão operacional para organizar atendimentos, contratos e comunicação interna. O SLA desse sistema prevê um RPO de 24 horas e um RTO de 7 dias. Durante um dia inteiro, colaboradores inserem dados de clientes, registros contratuais e atualizações operacionais. Ocorre uma falha às 18:00. O último backup válido é da meia-noite anterior.

Isso significa que:

• Tudo o que foi salvo no sistema após a meia noite pode ser definitivamente perdido:

o   necessidade de reinserção manual de informações;

o   inconsistências cadastrais;

o   perda de histórico de negociações;

o   erros operacionais decorrentes de dados incompletos.

• O sistema pode permanecer indisponível por até uma semana;

o   colaboradores ficam impossibilitados de executar tarefas;

o   contratos e agendas tornam-se inacessíveis;

o   atividades passam a depender de controles manuais improvisados.

Ainda, se a falha ocorrer numa sexta-feira, e o horário de suporte for só em horário comercial, em dias úteis, significa que a operação ficará parada até ao menos segunda-feira às 08:00. Se o tempo de solução foi de 8 horas, a solução somente será efetiva na terça feira.

Para alguns setores, como logística e varejo, isso é inaceitável. Na prática, a empresa não sofre apenas uma falha tecnológica, mas uma paralisação operacional completa.

Por essas razões, negociar os prazos de RPO e de RTO, assim como as janelas de suporte técnico não deve ser uma questão secundária. Para indisponibilidades críticas, o suporte deve ser 24/7 ou, no mínimo, cobrir os horários de pico da operação (incluindo sábados, se necessário).

O que Fazer Quando o SLA é Descumprido?

Quando o fornecedor falha em entregar a disponibilidade prometida ou ignora os prazos de resposta, a empresa contratante deve ter à disposição ferramentas contratuais que compensem o prejuízo ou forcem a regularização do serviço. Há diversas formas de lidar com esse descumprimento, e elas não são excludentes entre si.

A exigência de créditos de serviço ou descontos na fatura é a ferramenta mais comum em contratos de SaaS (Software as a Service). Em vez de uma multa paga em dinheiro, o fornecedor abate um percentual da fatura seguinte. O desconto é progressivo, dependendo do percentual descumprido. Por exemplo, se a disponibilidade cair de 99% para 97%, o cliente recebe 10% de desconto na mensalidade. Se cair para abaixo de 95%, o desconto pode chegar a 50% ou 100%.

Uma outra ferramenta são as multas contratuais. Elas são aplicadas geralmente em casos de descumprimentos graves ou reiterados. Pode ser um valor fixo por hora de indisponibilidade ou um percentual sobre o valor anual do contrato. É ideal para situações em que a queda do sistema gerou um prejuízo financeiro mensurável que o simples "desconto na fatura" não é capaz de cobrir.

Um último recurso seria executar a rescisão contratual por justa causa. Se o fornecedor descumpre sistematicamente os níveis de serviço (ex: três meses seguidos abaixo do SLA), a empresa tem o direito de encerrar o contrato sem pagar multas de rescisão antecipada.

Embora a rescisão pareça a solução lógica para um mau serviço, na prática, ela é uma medida extrema e complexa. Mudar de fornecedor de sistema não é como trocar de fornecedor de papelaria; envolve uma série de desafios que muitas vezes a empresa não está preparada para assumir, como a migração dos dados a outro sistema, a necessidade de treinar toda a equipe em uma nova interface, os custos de implementação de uma nova plataforma, integração com outras ferramentas, parametrização.

Os Riscos Regulatórios da Indisponibilidade

Até aqui, exploramos como a queda de um sistema paralisa equipes, gera prejuízos financeiros imediatos e mina a confiança do cliente. No entanto, os impactos ocorrem também no cenário jurídico e regulatório.

Um erro comum de interpretação é acreditar que a Lei Geral de Proteção de Dados (LGPD) se preocupa apenas com o "vazamento" de informações (perda da confidencialidade). Na verdade, todos os pilares da segurança da informação — confidencialidade, integridade e disponibilidade — devem estar garantidos.

A indisponibilidade prolongada ou a perda de acesso a dados pessoais (mesmo que não haja vazamento) pode ser classificada como um incidente de segurança que, a depender do caso, deverá ser notificado à ANPD (Autoridade Nacional de Proteção de Dados) e aos titulares dos dados envolvidos. As sanções podem chegar a 2% do faturamento, limitadas a R$ 50 milhões por infração, além da obrigatoriedade de dar publicidade ao incidente, o que agrava o dano reputacional.

A indisponibilidade também impede que um titular de dados possa exercer os direitos que lhe são garantidos pela LGPD, como o direito de acesso, de retificação, de portabilidade. E isso também pode ter repercussões econômicas.

O Papel do DPO na Negociação de SLA

Quando se fala em DPO, ainda é comum associar essa função apenas à treinamentos, elaboração de políticas e revisão de mapeamentos de dados. Na prática, porém, a atuação do DPO é (ou deveria ser) muito mais ampla: trata-se de uma função estratégica de gestão de riscos operacionais e jurídicos.

Embora muitas vezes visto apenas como um detalhe técnico, o SLA é, como vimos, um instrumento central de gestão de riscos. É nesse ponto que a presença do DPO faz diferença. O DPO, com seu conhecimento multidisciplinar, está capacitado para avaliar a criticidade que um determinado sistema tem para o negócio, determinar os níveis adequados de disponibilidade, e traduzir essas exigências em cláusulas objetivas e executáveis.

Um SLA mal negociado cria um desequilíbrio típico:

• O fornecedor limita sua responsabilidade técnica;

• O cliente assume integralmente o risco operacional.

  
  

O resultado é conhecido: dependência tecnológica sem mecanismos reais de cobrança.

Conclusão

A verdadeira maturidade em proteção de dados e governança tecnológica começa quando a empresa compreende que a privacidade não se limita a políticas estáticas ou documentos de gaveta; ela é indissociável da continuidade operacional. No cenário atual, a indisponibilidade é, por definição, uma vulnerabilidade de segurança e um risco de conformidade que pode paralisar o negócio e atrair sanções severas.

O DPO moderno atua de forma transversal, posicionando-se no centro estratégico onde convergem o jurídico, a tecnologia, a segurança da informação e a gestão de riscos. A experiência prática demonstra que muitos dos incidentes de dados mais graves não decorrem de ataques cibernéticos sofisticados, mas sim de relações contratuais mal estruturadas com fornecedores críticos. Sem métricas claras de severidade, disponibilidade e tempos de recuperação, a empresa fica à mercê da capacidade — ou da conveniência — do terceiro.

Atuar como DPO é, portanto, antecipar riscos antes que eles se materializem. Significa traduzir requisitos legais em obrigações técnicas, métricas verificáveis e garantias contratuais executáveis. É garantir que a empresa possua mecanismos reais para manter seus sistemas e dados seguros e acessíveis, mesmo diante das falhas que inevitavelmente ocorrerão.

Em última análise, a resiliência de uma organização não é fruto do acaso, mas da qualidade da sua governança. E essa capacidade de sobrevivência começa, invariavelmente, na forma como os contratos são negociados.