SOC 2 Type I ou Type II: como escolher o relatório adequado às exigências dos seus clientes

Quando um cliente pede SOC 2, a escolha entre Type I e Type II depende, antes de tudo, do que esse cliente aceita. O Type I avalia se os controles de segurança foram bem desenhados em uma data específica. O Type II avalia o desenho e também se os controles funcionaram de forma consistente ao longo de um período. O primeiro costuma servir para demonstrar prontidão em um primeiro momento. O segundo oferece uma comprovação mais robusta e tende a ser o esperado por clientes com processos maduros de avaliação de fornecedores.

A decisão correta combina três informações: a exigência do cliente, a maturidade dos controles da empresa e o prazo comercial. Este manual organiza esses pontos para que a escolha seja feita com segurança.

O que é o SOC 2, em termos práticos

O SOC 2 é um relatório de asseguração emitido por um auditor independente, segundo padrões do AICPA, o instituto norte-americano de contadores. Ele não é uma certificação. Em vez de um selo de aprovado ou reprovado, o relatório traz a descrição do sistema da empresa, os controles avaliados, os testes realizados e a opinião do auditor.

A avaliação segue os Trust Services Criteria, divididos em cinco categorias:

• Segurança: obrigatória em todo relatório SOC 2.
• Disponibilidade: incluída quando o cliente depende do funcionamento contínuo do serviço.
• Integridade de processamento: relevante quando o serviço processa transações ou dados que precisam estar completos e corretos.
• Confidencialidade: aplicável a informações sensíveis, como dados estratégicos dos clientes.
• Privacidade: voltada ao tratamento de dados pessoais.

A empresa escolhe, com base nos serviços e nas exigências dos clientes, quais categorias além de segurança entram no escopo.

Type I e Type II lado a lado

O Type II não substitui a necessidade de controles bem desenhados. Ele parte desse desenho e acrescenta a comprovação de que os controles foram executados na prática.

Por que os clientes pedem SOC 2

A exigência costuma aparecer em processos de homologação de fornecedores, renovação de contratos ou negociações com empresas de maior porte. Os motivos mais comuns são:

• avaliar o risco de terceiros que acessam ou armazenam dados do cliente;
• substituir questionários extensos de segurança por um relatório independente;
• atender às próprias exigências regulatórias e de auditoria do cliente;
• ter confiança na continuidade e na proteção dos serviços contratados.

Por isso, o relatório é lido pelas equipes de segurança, compras e compliance do cliente, que vão observar o escopo, os critérios incluídos, o período coberto e eventuais exceções apontadas pelo auditor.

O que confirmar com o cliente antes de escolher

Grande parte dos erros acontece porque a empresa decide o tipo de relatório sem entender exatamente o que foi pedido. Antes de qualquer decisão, vale confirmar:

• O cliente exige Type I, Type II ou aceita qualquer um dos dois?
• Se aceita o Type I, ele é suficiente para fechar o contrato ou é apenas uma etapa até o Type II?
• Existe um período mínimo de observação esperado para o Type II?
• Quais serviços, produtos ou ambientes precisam estar no escopo?
• Quais critérios, além de segurança, o cliente espera ver?
• Qual é o prazo para apresentar o relatório?
• O cliente aceita relatórios de outros padrões, como certificação ISO 27001, como alternativa ou complemento?
• Como ele trata o intervalo entre o fim do período avaliado e a data atual?

Essas respostas definem o tipo de relatório, o escopo e o cronograma. Sem elas, a empresa corre o risco de entregar um relatório que não atende à exigência.

Como escolher o caminho mais adequado

Essas tendências precisam ser confirmadas caso a caso. O Type I não é suficiente em todas as relações comerciais, e o Type II não é obrigatório para todas as empresas.

Dois exemplos para orientar a decisão

Primeira exigência de SOC 2. Uma empresa de software de gestão para clínicas, com cerca de 60 colaboradores, está em negociação com uma rede hospitalar. Na etapa de homologação, a área de segurança da rede pede um relatório SOC 2. A empresa tem políticas de acesso e backup, mas muitas rotinas ainda não são registradas de forma consistente. Ao conversar com o cliente, descobre que um Type I com escopo de segurança e confidencialidade é aceito para iniciar o contrato, desde que haja um plano para o Type II no ciclo seguinte. A empresa faz um diagnóstico de prontidão, formaliza os controles, define responsáveis e passa pela avaliação do Type I. Em paralelo, começa a gerar os registros que vão sustentar o Type II.

Comprovação de operação contínua. Uma plataforma SaaS de pagamentos, com controles de segurança maduros há alguns anos, entra em um processo de seleção de uma instituição financeira. O cliente informa que só aceita SOC 2 Type II, com período de observação que considere ao menos parte significativa do ano. A empresa já registra revisões de acesso, gestão de mudanças e tratamento de incidentes, então o foco da preparação é organizar as evidências, definir o período com o auditor e garantir que nenhum controle deixe de ser executado durante a observação.

Como preparar a empresa para o SOC 2

A preparação segue uma lógica parecida para os dois tipos, com uma diferença importante no Type II: os controles precisam operar e gerar registros durante todo o período avaliado.

• Diagnóstico de prontidão: comparar políticas, processos, controles e evidências existentes com os critérios aplicáveis.
• Definição do escopo: serviços, sistemas, ambientes, fornecedores críticos e critérios incluídos.
• Responsáveis: um dono para cada controle, com clareza sobre quem executa e quem revisa.
• Controles: implantação ou ajuste dos controles que faltam, como revisões de acesso, gestão de mudanças, monitoramento e resposta a incidentes.
• Registros: rotina para gerar e guardar evidências de execução.
• Acompanhamento: verificação periódica de que os controles estão sendo cumpridos.

No Type II, o período de observação é definido com o auditor e deve estar alinhado ao que os clientes esperam. Durante esse período, falhas na execução dos controles, como uma revisão de acesso não realizada ou um desligamento sem remoção de acesso no prazo, podem aparecer no relatório como exceções. Por isso, a empresa precisa começar o período com os controles estáveis e acompanhá-los de perto até o fim.

Também vale considerar dois pontos que costumam surgir na leitura do relatório pelo cliente. O primeiro são os fornecedores de infraestrutura, como provedores de nuvem, cujos controles normalmente são tratados por meio dos relatórios deles. O segundo são os controles complementares que o próprio cliente precisa manter para que a segurança do serviço funcione, e que o relatório descreve.

Quem faz o quê no processo

• A organização: define o escopo, implanta e executa os controles, gera as evidências e responde pela descrição do sistema.
• A consultoria de preparação: apoia o diagnóstico, a estruturação dos controles, a organização das evidências e o acompanhamento até a avaliação.
• O auditor independente: testa os controles e emite o relatório com sua opinião. Ele precisa ser independente de quem apoiou a preparação.

Separar esses papéis é essencial para a credibilidade do relatório perante os clientes.

O próximo passo é confirmar a exigência e avaliar a prontidão

Escolher entre SOC 2 Type I e Type II começa por entender o que o cliente aceita, segue pela avaliação da maturidade dos controles e termina em um plano de preparação compatível com o prazo comercial. Com essas informações, a empresa evita retrabalho e chega à avaliação com controles e evidências organizados.

Converse com os especialistas do Grupo GEP para avaliar a prontidão da sua empresa e planejar a preparação para SOC 2.