Português

Revisão de Segurança e Conformidade para Compradores de SaaS no Mercado Médio

O time jurídico entregou o relatório SOC 2 ao TI, o TI confirmou que o selo estava vigente e a aquisição registrou a revisão de segurança como concluída. Procedimento padrão. O vendor era uma empresa bem financiada em Série B, com uma página de segurança razoável e um mural de logos de clientes reconhecidos.

Onze meses depois, uma exploração de zero-day no middleware de API do vendor expôs 40.000 registros de clientes. O SOC 2 havia coberto os controles de acesso do vendor, os procedimentos de gestão de mudanças e o monitoramento de disponibilidade. Não havia coberto o componente específico de terceiros que falhou. E como o contrato continha uma cláusula ampla de limitação de responsabilidade, a recuperação jurídica da empresa foi mínima.

Ninguém havia sido negligente. O SOC 2 era genuíno. Mas uma certificação que informa que um vendor tinha bons controles no momento da auditoria não informa se esses controles cobrem o risco específico que se materializa no décimo primeiro mês.

Este guia é a revisão de segurança que vai além do selo.

Fatos Essenciais: Revisão de Segurança de SaaS em 2026

  • Aproximadamente 67% dos vendors de SaaS B2B mantêm um relatório SOC 2 Tipo II vigente, segundo o benchmark State of Trust da Vanta de 2024, mas menos de 30% incluem os critérios de Confidencialidade ou Privacidade no escopo.
  • A revisão de segurança de SaaS enterprise típica leva 41 dias de ponta a ponta (IANS Research, 2024), o que explica por que equipes do mercado médio implementam alternativas antes que a revisão seja concluída.
  • Estima-se que 54% das violações de terceiros em 2024 foram rastreadas até um vendor de SaaS ou nuvem no stack do comprador (Verizon DBIR, seção de Supply Chain de 2024).
  • Empresas do mercado médio (200 a 2.000 funcionários) ignoram a revisão formal de segurança em 38% das compras de SaaS, geralmente porque a aquisição não sinalizou o gasto como software (Gartner, 2024).
  • A cláusula de notificação de violação mediana em contratos SaaS é de 30 dias, 10 vezes mais longa do que o padrão de 72 horas do GDPR que a maioria dos compradores assume que se aplica.

Por Que as Certificações São Pontos de Partida, Não Pontos de Chegada

As certificações de segurança têm um propósito importante: elas criam um registro documentado de que um vendor aplicou determinados controles em um momento específico, verificado por terceiros. Isso é significativo. A explicação da AICPA sobre relatórios SOC esclarece exatamente a que cada tipo de relatório atesta e o que explicitamente não cobre.

Mas as certificações têm limitações estruturais:

Elas são retroativas. Um SOC 2 Tipo II cobre um período de observação de 6 a 12 meses que terminou antes de você assinar. A postura de segurança do vendor hoje pode ser diferente do que o relatório reflete, devido a mudanças de equipe, migrações de infraestrutura ou novas dependências de terceiros. Para um detalhamento em linguagem simples do que SOC 2, ISO 27001 e GDPR cada um cobre e onde se sobrepõem, o guia de frameworks de conformidade para compradores é o melhor ponto de partida.

Elas cobrem escopos definidos. O SOC 2 de um vendor pode cobrir seu produto principal, mas excluir explicitamente certas integrações de terceiros, parceiros de processamento de dados ou componentes de infraestrutura. A leitura da seção de escopo de um relatório SOC 2 frequentemente revela surpresas.

Elas não informam o que acontece quando as coisas dão errado. Uma certificação informa sobre controles e processos. Ela não informa com que rapidez o vendor vai notificá-lo sobre uma violação, como é o Playbook de resposta a incidentes dele ou como ele tratou historicamente eventos de segurança.

Ferramentas habilitadas para IA coletam mais. Ferramentas SaaS tradicionais processavam os dados que você lhes fornecia. Ferramentas habilitadas para IA processam cada vez mais dados inferidos (padrões, comportamentos, sinais agregados entre clientes) de formas que podem não ser cobertas pelos frameworks de certificação existentes.

A revisão de cinco camadas abaixo aborda todas essas lacunas.

A Revisão de Segurança Proporcional

A Revisão de Segurança Proporcional é um princípio do lado do comprador: ajuste a profundidade da sua revisão à sensibilidade dos dados que o vendor vai tocar, não ao valor do contrato ou ao prestígio do logo. Uma ferramenta de US$ 6/licença que ingere dados pessoais de clientes merece uma revisão mais profunda do que uma ferramenta de US$ 60/licença que vê apenas métricas de uso agregadas, e a maioria dos backlog de revisão do mercado médio cresce porque as equipes aplicam o mesmo questionário de 200 perguntas para todos os vendors, independentemente da exposição de dados. Classifique os vendors em níveis de revisão mínima (sem dados de clientes), padrão (dados internos) e elevada (dados regulamentados ou de clientes) antes de enviar o questionário.

Camada 1: Certificações: Leia o Relatório, Não o Selo

SOC 2 Tipo II

A expectativa padrão para qualquer ferramenta SaaS que lida com dados de negócios ou clientes. Confirme:

  • Período do relatório. O relatório deve cobrir os 6 a 12 meses imediatamente anteriores à sua revisão. Um SOC 2 de 18 meses atrás não está vigente.
  • Critérios de Trust Service incluídos. O SOC 2 tem cinco critérios: Segurança (CC), Disponibilidade (A), Integridade de Processamento (PI), Confidencialidade (C) e Privacidade (P). A maioria dos vendors cobre apenas Segurança e Disponibilidade. Confirme quais critérios estão cobertos e verifique se os relevantes para o seu caso de uso estão incluídos.
  • Escopo. Leia a seção de escopo com atenção. Quais sistemas, produtos e infraestrutura estão incluídos? O que está excluído?
  • Opinião qualificada. Se o relatório contiver exceções ou opiniões qualificadas, entenda o que são. Uma exceção menor em gestão de mudanças é diferente de uma exceção em controle de acesso.

O que perguntar:

  • Posso receber o relatório SOC 2 Tipo II completo sob NDA?
  • Quais critérios de Trust Service o seu relatório cobre?
  • Qual foi o período de auditoria e quando está agendada a próxima auditoria?
  • Há exceções ou qualificações no relatório atual?

ISO 27001

Relevante se você opera em mercados internacionais ou setores regulamentados. A ISO 27001 cobre um sistema de gestão de segurança da informação (ISMS), que não é o mesmo que o SOC 2 e não é intercambiável. Um vendor com ISO 27001 mas sem SOC 2 tem um perfil diferente de um com SOC 2 mas sem ISO 27001.

Verifique o escopo do certificado: ele deve corresponder aos produtos e infraestrutura que você está comprando.

Teste de Penetração

Solicite a data e o escopo do teste de penetração mais recente, quem o realizou e quais foram as descobertas materiais. Vendors que nunca realizaram um pen test ou que recusam compartilhar resultados resumidos são um sinal significativo de risco.

Uma resposta credível: "Realizamos pen tests anuais com [empresa externa]. O mais recente foi em [data] e o relatório resumido está disponível sob NDA. As descobertas materiais foram remediadas."

Camada 2: Tratamento de Dados e Localização

Esta camada trata do que acontece com seus dados depois que eles entram nos sistemas do vendor.

Geografia de Armazenamento de Dados

Onde seus dados ficam afeta suas obrigações de conformidade, sua exposição a solicitações de dados de governos estrangeiros e seus direitos sob regulamentos de privacidade como o GDPR.

Perguntas a fazer:

  • Onde os bancos de dados de produção estão hospedados geograficamente?
  • Onde os backups são armazenados?
  • Você oferece opção de residência de dados para EUA/UE/região específica, se necessário?
  • Se você usa AWS, Azure ou GCP, quais regiões?

Retenção e Exclusão de Dados

  • Por quanto tempo os dados do cliente são retidos durante um contrato ativo?
  • Por quanto tempo os dados do cliente são retidos após a rescisão do contrato?
  • Qual é o processo de exclusão e você pode fornecer verificação de que a exclusão ocorreu?
  • Os backups são excluídos no mesmo prazo que os dados de produção?

Sub-processadores de Terceiros

Todo vendor de SaaS usa infraestrutura, analytics, suporte e provedores de IA de terceiros. Cada um desses provedores é um ponto potencial de exposição de dados. Solicite uma lista atual de sub-processadores e verifique se algum está em jurisdições com preocupações significativas de privacidade.

Dados de Treinamento de IA (Crítico para Ferramentas Habilitadas para IA)

Se a ferramenta do vendor inclui funcionalidades de IA, esta se torna a pergunta mais importante sobre tratamento de dados:

  • Os dados do cliente são usados para treinar modelos de IA do vendor? (Modelo compartilhado ou isolado por cliente?)
  • Se sim, os clientes podem optar por não participar?
  • Os resultados de inferência dos dados do cliente são compartilhados com outros clientes?
  • Qual é o adendo de processamento de dados para tratamento específico de IA?

Camada 3: Modelo de Controle de Acesso

Como o vendor controla o acesso aos seus dados (e à sua própria infraestrutura) é um indicador direto de maturidade de segurança.

Controles de acesso do lado do vendor:

  • Quem no vendor tem acesso aos dados do cliente? (Suporte, engenharia, equipes de dados?)
  • Qual é o processo de aprovação para acesso de funcionários do vendor aos dados de produção?
  • O acesso é registrado e auditado?
  • A autenticação multifator é exigida para funcionários do vendor que acessam sistemas de produção?

Controles de acesso do lado do cliente:

  • O produto suporta controle de acesso baseado em papéis (RBAC)?
  • O Single Sign-On (SSO) está disponível e está incluído no plano base ou é um complemento?
  • A autenticação multifator é exigida para usuários finais, disponível ou opcional?
  • O que acontece com o acesso a dados quando um usuário é desprovisionado?

O problema da taxa de SSO: Muitos vendors SaaS cobram extra pelo SSO, que é um controle de segurança que deveria ser padrão. Essa prática é amplamente documentada na comunidade de segurança. A visão geral do Single Sign-On na Wikipedia explica por que a federação de identidade é um controle de segurança fundamental, não um recurso premium. Se sua empresa usa um IdP (Okta, Azure AD, Google Workspace), o SSO é um requisito de segurança relevante. Descubra se ele está incluído antes de ver o preço no formulário de pedido. Esse tipo de padrão de custo oculto é exatamente o que a modelagem de TCO para SaaS captura na linha de custo de integração da Categoria 3.

Camada 4: Política de Notificação de Violações

Quando algo der errado (e estatisticamente algo vai dar errado com qualquer vendor que você usar por tempo suficiente), o que você tem direito de saber e quando importa significativamente.

Perguntas a fazer:

  • Qual é o compromisso contratual para os prazos de notificação de violação? (72 horas é o padrão do GDPR; muitos contratos oferecem 30 dias, que é muito lento)
  • O que constitui uma violação notificável segundo a sua definição versus um incidente de segurança?
  • Você teve uma violação notificável nos últimos dois anos? Se sim, o que aconteceu e qual foi o resultado?
  • Qual é o seu procedimento de resposta a incidentes e quem é o contato designado?
  • O seu seguro de responsabilidade cibernética cobre os custos de notificação de clientes?

Padrão contratual mínimo: Obtenha um SLA de notificação de violação por escrito. 72 horas a partir da descoberta para qualquer coisa envolvendo dados pessoais é o padrão a negociar. Isso espelha o requisito estabelecido pelo Artigo 33 do texto do regulamento GDPR. Se o vendor resistir, entenda o motivo.

Camada 5: Histórico de Divulgação de Vulnerabilidades

Incidentes de segurança passados, quando bem gerenciados, são evidência de maturidade, não um fator de desqualificação. Um vendor que nunca divulgou uma vulnerabilidade ou não foi atacado (improvável) ou não tem um programa de divulgação (um problema). O Cybersecurity Framework do NIST define a divulgação responsável e a gestão de vulnerabilidades como práticas centrais das funções "Responder" e "Recuperar". Vendors que não conseguem referenciá-las provavelmente não operam nesse nível de maturidade. Para ferramentas habilitadas para IA, essas perguntas se estendem à inferência de modelos e à exposição de dados de treinamento, que o guia de avaliação de SaaS habilitado para IA aborda em detalhes.

Perguntas a fazer:

  • Você tem um programa de bug bounty ou política de divulgação responsável?
  • Você divulgou algum CVE (Common Vulnerabilities and Exposures) nos últimos dois anos?
  • Se sim, qual foi o prazo da descoberta até o patch e a divulgação?
  • De quais bibliotecas ou componentes de terceiros seu produto depende e como você rastreia vulnerabilidades neles?

O Questionário de Revisão de Segurança (20 Perguntas)

Envie este questionário antes da chamada de revisão de segurança. Ele revela lacunas antes que seu tempo seja gasto nelas.

Certificações

  1. Você tem um relatório SOC 2 Tipo II vigente? Quais critérios de Trust Service ele cobre?
  2. A certificação ISO 27001 está no escopo dos produtos que estamos comprando?
  3. Qual foi a data do seu teste de penetração mais recente e um resumo está disponível?

Tratamento de Dados 4. Onde os dados de produção são armazenados geograficamente? Onde ficam os backups? 5. Você oferece opções de residência de dados para [nossa região]? 6. Qual é a sua política de retenção de dados durante e após a rescisão do contrato? 7. Quais sub-processadores lidam com nossos dados e onde estão baseados? 8. Os dados do cliente são usados para treinar seus modelos de IA? Os clientes podem optar por não participar?

Controle de Acesso 9. Quem na sua empresa pode acessar dados de clientes de produção e qual é o processo de aprovação? 10. O acesso à produção é registrado e auditável? 11. O SSO/SAML está disponível e está incluído no plano base? 12. O produto suporta controle de acesso baseado em papéis (RBAC)?

Notificação de Violações 13. Qual é o prazo contratual de notificação de violação? 14. Você teve uma violação notificável ou incidente de segurança material nos últimos dois anos? 15. Quem é o contato de segurança designado em caso de incidente?

Gestão de Vulnerabilidades 16. Você tem um programa de bug bounty ou divulgação responsável? 17. Você divulgou algum CVE nos últimos 24 meses? 18. Como você rastreia e corrige vulnerabilidades em bibliotecas de terceiros?

Contrato e Conformidade 19. Posso receber o DPA e todos os adendos de processamento de dados antes de assinar? 20. Qual é a limitação de responsabilidade por uma violação de segurança que afeta os dados dos nossos clientes?

Scorecard de Segurança do Vendor

Use este para resumir a revisão para um tomador de decisões não técnico:

Domínio Pontuação (1 a 5) Observações
Vigência e escopo da certificação
Transparência no tratamento de dados
Maturidade do controle de acesso
Compromisso de notificação de violações
Histórico de divulgação de vulnerabilidades
Tratamento de dados de IA (se aplicável)
Geral

Pontuação de 4 a 5: Prossiga com revisão contratual padrão. Pontuação 3: Prossiga com requisitos específicos de remediação no contrato. Pontuação abaixo de 3: Escale para a liderança de TI antes de prosseguir; considere se este vendor consegue atender aos seus requisitos.

Como o Rework Aborda a Revisão de Segurança nos Dois Lados da Mesa

O Rework mantém SOC 2 Tipo II (critérios de Segurança, Disponibilidade e Confidencialidade), com opções de residência de dados nas regiões EUA e UE e um compromisso de notificação de violações em 72 horas no nosso DPA padrão, sem negociação necessária para igualar o padrão do GDPR. Os dados do cliente nunca são usados para treinar modelos de IA compartilhados, os sub-processadores são listados publicamente e o SSO está incluído em todos os planos pagos, sem ser bloqueado atrás de um complemento enterprise.

Do outro lado da mesa, o Rework Work Ops é o que equipes de TI e segurança do mercado médio usam para conduzir a própria revisão de segurança como um processo interfuncional. O Work Ops (a partir de US$ 6/usuário/mês) oferece uma fila de intake compartilhada onde a aquisição sinaliza novos pedidos de SaaS, os encaminha automaticamente para TI ou segurança com base no nível de sensibilidade de dados, rastreia as respostas ao questionário em relação aos prazos de assinatura do contrato e mantém jurídico, finanças e o departamento solicitante no mesmo cronograma. Ele transforma o ciclo médio de revisão de 41 dias em um Workflow previsível em vez de um thread de Slack que morre após o terceiro follow-up.

Perguntas Frequentes

Perguntas Frequentes sobre Revisão de Segurança e Conformidade de SaaS

Quais certificações de segurança todo SaaS deve ter?

Para qualquer ferramenta que toque dados de clientes ou de negócios, SOC 2 Tipo II (critérios de Segurança e Disponibilidade, no mínimo) é a linha de base. Acrescente ISO 27001 se você opera na UE ou em setores regulamentados, e um DPA vigente se dados pessoais fluírem pelo vendor. Certificações abaixo do SOC 2 Tipo II, como um SOC 2 Tipo I, um "whitepaper de segurança" auto-atestado ou uma página de central de confiança sem um relatório subjacente, não são equivalentes e devem ser tratadas como lacuna, não como aprovação.

Quando devo exigir um questionário de segurança completo?

Classifique por sensibilidade de dados. Revisão mínima (questionário curto, documentos públicos do trust center) para ferramentas que não veem dados de clientes. Revisão padrão (SIG Lite de 30 a 40 perguntas) para ferramentas com dados internos de negócios. Revisão elevada (SIG completo ou CAIQ, mais relatório SOC 2 sob NDA e markup do DPA) para qualquer coisa que toque dados pessoais de clientes, dados financeiros, código-fonte ou dados regulamentados. Aplicar o mesmo formulário de 150 perguntas para todos os vendors é o motivo pelo qual os backlogs de revisão crescem mais rápido do que fecham.

Quanto tempo deve levar uma revisão de segurança de SaaS?

Para um processo em níveis, a revisão mínima leva 2 a 5 dias úteis, a padrão 10 a 15 dias úteis, e a elevada 3 a 6 semanas. O benchmark da IANS de 2024 de 41 dias reflete processos sem níveis em que ferramentas de baixo risco ficam na mesma fila que as de alto risco. Se sua revisão elevada está consistentemente acima de 8 semanas, o gargalo é quase sempre o markup jurídico do DPA, não o questionário de segurança em si.

Um vendor de SaaS pode pular o SOC 2 e ainda ser seguro?

Vendors em estágio inicial (pré-Série A, com menos de 50 funcionários) às vezes operam com segurança sem um SOC 2 simplesmente porque o custo da auditoria ainda não coube no orçamento. Para casos de uso de baixa sensibilidade, um vendor credível com ISO 27001, um resumo de pen test publicado, um DPA claro e um cronograma declarado para o SOC 2 pode ser aceitável com linguagem contratual compensatória. Para qualquer coisa que lide com dados pessoais de clientes ou dados regulamentados, "estamos trabalhando no SOC 2" não é um substituto: exija-o antes do lançamento em produção e inclua-o no contrato como um marco.

Qual é o maior sinal de alerta em uma revisão de segurança?

Um vendor que não compartilha o relatório SOC 2 sob NDA. O selo no site é marketing; o relatório é o artefato. Vendors que desviam com "nossa equipe jurídica não nos permite compartilhar o relatório" estão ou deturpando a certificação, têm exceções materiais que não querem que compradores vejam, ou têm um escopo de relatório que não cobre o produto que você está comprando. O segundo maior: recusar-se a comprometer-se com notificação de violações em menos de 30 dias.

Quem é responsável pela revisão de segurança: TI, equipe de segurança ou jurídico?

No mercado médio (200 a 2.000 funcionários), a revisão de segurança geralmente fica com TI ou uma pequena função de segurança, com o jurídico sendo responsável pelo markup do DPA e do contrato. O ponto de falha ocorre quando ninguém é responsável pela transição: o TI aprova os controles, o jurídico aprova os termos, mas ninguém verifica se a linguagem contratual realmente reflete o que o TI verificou. Designe um único responsável pela revisão por vendor: geralmente TI para o nível elevado, aquisição para o padrão, e torne o jurídico um revisor, não um guardião.

Devo revisitar vendors que já aprovei?

Sim, em uma cadência com base em risco. Vendors de nível elevado anualmente (novo relatório SOC 2, lista atualizada de sub-processadores, atualização de pen test). Vendors de nível padrão a cada 2 anos ou na renovação. Vendors de nível mínimo somente em mudança material (aquisição, expansão de região, nova funcionalidade de IA). Um vendor adquirido por uma empresa maior ou que se expande para uma nova região de processamento de dados deve acionar uma revisão fora do ciclo regular, independentemente do nível.

Saiba Mais