Como definir o escopo do seu primeiro relatório SOC 2

O escopo determina quanto custa um relatório SOC 2, quanto tempo leva e quão útil ele é para os clientes. A maioria dos erros de primeira vez são erros de escopo, cometidos na primeira semana.

Um relatório SOC 2 abrange um sistema: o serviço que os clientes contratam e tudo o que está por trás dele. Se você traçar essa fronteira largo demais, passará meses evidenciando controles que ninguém pediu. Se a traçar estreito demais, o relatório não responderá à pergunta do cliente. Os erros mais caros na primeira vez com SOC 2 são cometidos na semana de definição do escopo.

Decisão 1: qual sistema

Comece pelo que os clientes contratam e de que dependem. Para a maioria das empresas de software, isso é a plataforma de produção: a aplicação, sua infraestrutura e repositórios de dados, as pessoas que a desenvolvem e operam, e os processos que seguem. Normalmente fora do escopo: TI corporativa interna que nunca toca dados de clientes, outras linhas de produtos e sistemas de vendas.

Registre a fronteira logo no início, porque ela se torna a descrição do sistema no relatório, e todo controle deve funcionar em tudo o que estiver dentro dela, todos os dias do período de observação.

Decisão 2: quais critérios

Segurança, os critérios comuns CC1 a CC9, é obrigatória. Acrescente outros apenas quando os clientes precisarem deles:

Disponibilidade, se os clientes dependerem de compromissos de uptime.
Confidencialidade, se você mantiver dados de clientes classificados como confidenciais (a maioria dos serviços B2B).
Integridade de Processamento, se os clientes dependerem de você para processar seus dados corretamente: pagamentos, folha de pagamento, faturamento.
Privacidade, se você tratar informações pessoais para fins próprios e os clientes solicitarem. A maioria de seus critérios não tem equivalente em frameworks de segurança, como mostra nossa análise de SOC 2 e ISO 27001.

Fotografia de fita adesiva de mascaramento e uma trena sobre um piso de concreto, onde um retângulo foi demarcado com fita — Demarque o limite antes de tudo.

Decisão 3: organizações prestadoras de serviço

Seu provedor de nuvem, processador de pagamentos ou provedor de banco de dados gerenciado executa controles dos quais você depende. Você escolhe entre:

Exclusão (carve-out) (mais comum): os controles deles ficam excluídos; você descreve para que depende deles e demonstra que analisa os próprios relatórios SOC 2 deles.
Inclusivo: os controles deles são testados dentro do seu relatório. Isso exige a cooperação deles e é raro entre grandes provedores.

Decisão 4: controles complementares de entidades usuárias

Liste os controles que seus clientes devem operar para que os seus funcionem: gerenciar as próprias contas de usuário, proteger suas chaves de API, configurar seu SSO. Mantenha-os realistas e poucos, porque os clientes os leem e suas equipes de segurança questionarão uma lista pouco razoável.

Decisão 5: Tipo I ou Tipo II, e o período

O Tipo I é mais rápido; o Tipo II é o que a maioria dos clientes deseja. Para um primeiro Tipo II, é comum um período de três a seis meses. Inicie-o somente quando os controles estiverem em funcionamento há algumas semanas, para que o início do período não fique cheio de exceções.

Checklist de definição de escopo

Antes do kickoff com sua firma de CPA, tenha respostas para estas perguntas:

Qual produto ou serviço o relatório descreve e para que os clientes dependem dele?
Quais ambientes estão no escopo (somente produção ou também homologação)?
Quais contas de nuvem, regiões e repositórios de dados?
Quais equipes e funções operam o sistema?
De quais organizações prestadoras de serviço o sistema depende, e você tem os relatórios delas?
Quais categorias dos Trust Services Criteria, e por quê?
Quais controles complementares de entidades usuárias os clientes precisarão operar?
Tipo I primeiro, ou direto para o Tipo II? Qual período?
Quais frameworks ou auditorias existentes permitem reaproveitar evidências?

As respostas por escrito se tornam o primeiro rascunho da descrição do sistema e economizam semanas de idas e vindas. Se você já possui a ISO 27001, o relatório de lacunas ISO 27001 → SOC 2 responde à última pergunta.

Erros de escopo que mais custam

Incluir TI corporativa "por precaução": isso dobra a quantidade de sistemas a evidenciar.
Adicionar Privacidade ou Integridade de Processamento por soarem bem: cada um acrescenta controles e evidências para todo o período.
Uma descrição do sistema que não corresponde à realidade: os auditores testam o que você escreveu.
Iniciar o período antes de os controles estarem em funcionamento: exceções do primeiro mês permanecem no relatório.

Nosso guia de SOC 2 cobre o processo completo; a página do framework SOC 2 lista cada critério com seus mapeamentos; e, se você já possui outro framework, a análise de lacunas mostra o quanto ele aproveita.

Perguntas

Qual é o escopo mínimo de um relatório SOC 2?

A categoria Segurança (os critérios comuns, CC1 a CC9) para um sistema definido. Disponibilidade, Confidencialidade, Integridade de Processamento e Privacidade são opcionais.

O que é uma exclusão (carve-out) no SOC 2?

Excluir do seu relatório os controles de uma organização prestadora de serviço (por exemplo, os controles de data center do seu provedor de nuvem), ao mesmo tempo em que se descreve para que você depende dela e como a monitora.

Dados atualizados em 2026-10-27: os números deste artigo são calculados a partir da correspondência atual e são atualizados quando ela muda. Correspondência um crosswalk publicado (NIST, ENISA, CIS, PCI SSC) estabelece a correspondência · Editorial Juízo editorial da ControlMapping onde não existe crosswalk; o motivo é indicado · compartilha apenas um resultado do CSF 2.0: vale verificar, mas não é um mapeamento · Sem mapeamento em nossos dados nada mapeado em nossos dados; muitas vezes é trabalho novo, mas verifique as notas de cobertura. Não é aconselhamento de conformidade.

Definir o escopo de um primeiro relatório SOC 2 sem se comprometer em excesso