# SLA e Compliance: O que exigir do provedor

**Autor:** Maicon Ramos
**Categoria:** Hospedagem & VPS
**Publicado:** 2025-11-15
**Atualizado:** 2026-07-21
**Canonical:** https://runzos.com/sla-e-compliance-o-que-exigir-do-provedor

SLA, Uptime e Conformidade (SOC2/GDPR) é o conjunto que define níveis de serviço como disponibilidade e indica controles de segurança e proteção de dados exigidos por clientes e reguladores. SLA (Service Level Agreement) traduz expectativas de desempenho — uptime, tempos de resposta e suporte —, enquanto SOC 2 e GDPR (Regulamento Geral de Proteção de Dados) comprovam auditoria, controle de acesso e governança de dados. Eu uso esses parâmetros para comparar provedores, avaliar risco operacional e de privacidade, e fechar contratos com garantias claras e consequências para falhas. O que é SLA, Uptime e Conformidade (SOC2/GDPR)? 💡 Antes de escolher: a Calculadora de Custo de VPS e Hospedagem compara o preço real de 41 planos — promoção, renovação e câmbio — e mostra qual sai mais barato pro seu caso. SLA formaliza expectativas de serviço, uptime quantifica disponibilidade e compliance como SOC 2 e GDPR comprova controles. O escopo é avaliar riscos ao contratar uma plataforma de IA; não cobre a governança interna do cliente nem obrigações setoriais específicas. Pense como um contrato de energia: há garantias, limites e consequências quando a entrega falha. Métricas de disponibilidade costumam aparecer como percentuais mensais, por exemplo 99,9%. É essencial entender janelas de manutenção, exclusões de força maior e o que exatamente é medido, como API em produção, regiões específicas ou componentes críticos. Tempos de resposta são descritos por latências em percentis, como P50, P95 e P99. SLOs traduzem metas internas, enquanto SLAs tornam compromissos contratuais. Verifique limites de taxa, throughput e como o provedor coleta SLIs. Penalidades geralmente aparecem como créditos de serviço, com tetos, prazos de reivindicação e exclusões. Eles reduzem faturas futuras, mas não substituem indenizações por danos indiretos ou lucros cessantes. SOC 2 atesta controles sobre Segurança, Disponibilidade, Confidencialidade, Integridade de Processamento e Privacidade. Avalie se o relatório é Tipo II (operacional ao longo do tempo), o período coberto e exemplos de controles como acesso e mudança. GDPR exige base legal clara, como contrato, consentimento ou interesse legítimo, e garante direitos de acesso, apagamento, portabilidade e oposição. Para riscos elevados, procure DPIA e processos de solicitações de titulares. Segurança deve incluir criptografia em trânsito (TLS) e em repouso, gestão de chaves, IAM com menor privilégio, MFA e registros de acesso. Confirme segregação de ambientes e proteção de segredos. Gestão de incidentes pede critérios de severidade, prazos de notificação, definição de violação de dados e roteiro de contenção, análise de causa e ação preventiva, com comunicação transparente. Auditoria requer evidências como relatórios SOC, resumos de testes de intrusão, política de vulnerabilidades, retenção de logs e métricas operacionais. Entenda o processo de compartilhamento sob NDA. Residência de dados envolve escolha de regiões, restrições geográficas, subprocessadores e SCCs. O DPA precisa definir papéis de controlador/operador, finalidade, retenção e fluxos transfronteiriços. Métricas de disponibilidade Métricas de disponibilidade respondem à pergunta essencial: o serviço estava utilizável quando o cliente precisou? Diferentemente de latência ou throughput, elas medem a presença do serviço, não sua velocidade. Essa distinção evita confundir lentidão com indisponibilidade. O indicador mais conhecido é o uptime, expresso em percentuais e “nines” (por exemplo, 99,9%). O contrato deve definir a janela de medição — mensal ou anual — e o que constitui “disponível”. Sem essa precisão, o mesmo número pode contar histórias muito diferentes. A disponibilidade depende também de exclusões explícitas. Janelas de manutenção programada podem não entrar no cálculo, assim como falhas causadas por terceiros. É crucial saber se tais períodos são limitados por duração, frequência e aviso prévio. Em arquiteturas complexas, a disponibilidade efetiva é multiplicativa: se você depende de dois serviços de 99,9%, o conjunto pode entregar menos que 99,9%. Por isso, métricas por componente e por região ajudam a entender a realidade de uma implantação multi-região ou com failover. Muitos provedores separam plano de controle (APIs administrativas) e plano de dados (execução/serving). O SLA pode cobrir apenas o dado, enquanto o controle sofre interrupções sem penalidade. Essa distinção afeta operações de deploy e escala em momentos críticos. Nem toda falha é total. Degradação parcial — como limites de taxa mais rígidos ou funcionalidades indisponíveis — pode não ser tratada como downtime, embora reduza a utilidade do serviço. Uma métrica complementar é o orçamento de erro, que quantifica quanto tempo de falha é “permitido” para atingir o objetivo de disponibilidade. Indicadores operacionais como MTTR (tempo médio de reparo) e MTBF (tempo médio entre falhas) dão contexto à recuperação, mas não substituem o uptime. Eles esclarecem resiliência e previsibilidade ao longo do ciclo de incidentes. Uma analogia útil: disponibilidade é como a porta de uma loja estar aberta; latência é a fila no caixa. Para avaliar riscos, confirme a fórmula de cálculo, as exclusões aceitas e a segmentação por região e plano, garantindo que a disponibilidade percebida pelo usuário corresponda ao número prometido no SLA. Dúvidas frequentes — SLA, Uptime e Conformidade (SOC2/GDPR) para plataformas de IA Que níveis de SLA devo exigir antes de migrar workloads de IA? Peça SLAs por componente (API/serving, plano de controle, console) e por região; exija métricas claras como disponibilidade percentual (ex.: 99,9% para serviços padrão e 99,99% para criticidade alta), SLO associado e histórico de disponibilidade. Confirme janela de medição (mensal/ anual), error budget e planos de failover/replicação regional. Como o uptime é calculado e quais exclusões devo verificar? Exija a fórmula exata e a janela usada no cálculo; verifique exclusões comuns (manutenções programadas com aviso prévio, eventos de força maior, falhas de terceiros) e limites para janelas de manutenção. Pergunte também como são tratadas degradações parciais, que podem não contar como downtime mas impactam a utilidade do serviço. Que tipo de compensação e processo de reivindicação devo aceitar? Créditos de serviço são o padrão: exija teto, prazos e evidências necessárias, preferencialmente solicitação automatizada via portal e prazo definido para aplicação dos créditos. Tenha em mente que créditos raramente cobrem danos indiretos — se isso for crítico, negocie cláusulas contratuais específicas ou garantias adicionais. Como comprovar SOC 2 e o que pedir no relatório? Peça, preferencialmente, um relatório SOC 2 Tipo II cobrindo ao menos Segurança e Disponibilidade, com o período coberto claramente indicado. Solicite o sumário executivo e, sob NDA se necessário, acesso a evidências ou uma bridge letter; verifique controles de gestão de mudanças, controle de acesso, segregação de ambientes e resultados de testes de vulnerabilidade. O que exigir em relação ao GDPR, DPA e residência de dados? Exija um DPA claro que defina papéis (controlador vs operador), finalidade, períodos de retenção e lista de subprocessadores. Peça opções de residência regional e cláusulas para transferências internacionais (SCCs ou mecanismos equivalentes), além de procedimentos documentados para atender solicitações de titulares (acesso, retificação, exclusão). Quais prazos e evidências devo definir para resposta a incidentes? Defina níveis de severidade e prazos: notificação inicial para incidentes críticos dentro de 24 horas, atualizações regulares e relatório técnico detalhado (ex.: 30 dias) com causa raiz e ações corretivas. Exija roteiro de contenção, evidências forenses quando aplicável e relatórios de “lessons learned”; prefira provedores que realizem exercícios tabletop periódicos. Quais controles técnicos e operacionais devo exigir para proteger dados sensíveis? Peça TLS para trânsito e criptografia em repouso com KMS; prefira opção BYOK para chaves quando necessário. Exija IAM com princípio do menor privilégio e MFA, segregação clara entre ambientes (produção/teste), logs de auditoria imutáveis com retenção definida, evidências de testes de penetração e um programa de gestão de vulnerabilidades e patches.

## Leia também

- [BYOK: traga sua chave para X/Twitter](https://runzos.com/byok-traga-sua-chave-para-x-twitter/)
- [Staging: teste seu site antes de publicar](https://runzos.com/staging-teste-seu-site-antes-de-publicar/)
- [Multi‑client: gestão e permissões por perfil](https://runzos.com/multi‑client-gestao-e-permissoes-por-perfil/)
- [White‑label: rebrand de soluções SaaS](https://runzos.com/white‑label-rebrand-de-solucoes-saas/)