SOC 2 para startups: o que e, Type I vs Type II e como uma equipe enxuta se prepara para a auditoria

O que SOC 2 e de fato (e o que nao e)

SOC 2 e um relatorio de atestacao definido pela AICPA (American Institute of Certified Public Accountants), produzido sob a norma de atestacao SSAE 18 (AT-C 105 e AT-C 205). A sigla vem de System and Organization Controls. Diferente de uma certificacao como a ISO/IEC 27001 — em que um organismo certificador emite um certificado padronizado —, o SOC 2 e um documento descritivo: o auditor avalia os controles da sua empresa de servicos contra os Trust Services Criteria e emite uma opiniao. Por isso o cliente nao recebe um 'selo' para o site; ele recebe (em geral sob NDA) um relatorio que pode chegar a dezenas de paginas, com a descricao do sistema, a tabela de controles e os testes realizados.

E util separar a familia SOC. O SOC 1 trata de controles relevantes para demonstracoes financeiras dos clientes (ICFR) e e auditoria do mundo contabil. O SOC 2 trata de controles operacionais de seguranca e correlatos, e e o que o mercado de software e fintech pede. Existe ainda o SOC 3, que e uma versao resumida e publica do SOC 2 — util para colocar no site sem expor detalhes do relatorio completo. Para uma startup que vende SaaS, o alvo quase sempre e o SOC 2; o SOC 3 e um derivado opcional.

Quem emite e parte essencial. SOC 2 so pode ser assinado por um CPA licenciado ou por uma firma de CPA registrada — nao por uma consultoria de seguranca, nem pela propria Decripte ou por qualquer parceiro que prepare a empresa. Isso e por desenho: a atestacao exige independencia do auditor. O papel de um parceiro de preparacao e diferente e legitimo: implementar controles, fechar lacunas, organizar evidencia e conduzir um readiness assessment antes de o auditor entrar. Confundir os dois papeis e um erro comum — a empresa que 'audita' e 'prepara' ao mesmo tempo compromete a independencia que da valor ao relatorio.

Vale dizer o que o relatorio nao significa. Um SOC 2 limpo (opiniao sem ressalvas) atesta que, no escopo definido e no periodo avaliado, seus controles foram desenhados de forma adequada e — no Type II — operaram com efetividade. Nao e garantia de que voce nunca tera um incidente, nem cobre sistemas fora do escopo. Ler a secao de escopo e a opiniao do auditor e tao importante quanto ver se o relatorio existe.

Os 5 Trust Services Criteria: o que entra no seu escopo

Os Trust Services Criteria (TSC) sao as cinco categorias da AICPA contra as quais o auditor avalia seus controles. A primeira, Security, e obrigatoria em todo SOC 2 e tambem e chamada de Common Criteria (CC1 a CC9). Ela cobre a base: ambiente de controle e governanca, comunicacao, avaliacao de risco, atividades de monitoramento, controles logicos e fisicos de acesso, operacoes de sistema, gestao de mudancas e mitigacao de risco. Na pratica, e onde moram MFA, gestao de acessos, logging, resposta a incidentes, gestao de vulnerabilidades e mudancas. Os outros quatro criterios sao adicionados ao escopo conforme a promessa que sua empresa faz ao cliente — adicionar um criterio significa mais controles a desenhar e mais evidencia a produzir, entao a decisao e estrategica, nao automatica.

Availability (disponibilidade) cobre se o sistema esta disponivel para operacao e uso conforme o comprometido. Entra quando voce vende um SLA de uptime ou quando a continuidade e parte central do valor: aqui aparecem monitoramento de capacidade, backups, recuperacao de desastres e testes de plano de continuidade. Confidentiality (confidencialidade) trata da protecao de informacao designada como confidencial — criptografia, controles de acesso a dados sensiveis, retencao e descarte. E o criterio mais comumente adicionado por SaaS B2B porque cobre o dado do cliente que nao e necessariamente dado pessoal (contratos, codigo, dados de negocio).

Processing Integrity (integridade de processamento) verifica se o processamento do sistema e completo, valido, preciso, oportuno e autorizado. Faz sentido para empresas cujo nucleo e processar transacoes ou calcular resultados — fintechs de pagamento, folha, conciliacao, antifraude — onde o cliente precisa confiar que o que entra e processado corretamente. Privacy (privacidade) trata da coleta, uso, retencao, divulgacao e descarte de informacao pessoal de acordo com o aviso de privacidade da entidade e com os criterios da AICPA. Atencao a uma confusao frequente: Privacy lida com dados pessoais de individuos; Confidentiality lida com informacao confidencial em geral. Muitas startups que ja tratam LGPD se beneficiam de incluir Privacy, mas isso amplia o escopo e a evidencia exigida.

A regra pratica de escopo para uma startup enxuta: comece com Security (que e mandatorio) e adicione apenas os criterios que voce de fato promete contratualmente ou que destravam o pipeline atual. Confidentiality costuma ser o primeiro adendo natural para SaaS; Availability entra quando ha SLA; Processing Integrity e Privacy entram quando o modelo de negocio os torna materiais. Cada criterio extra adiciona controles e meses de evidencia — escopo deliberado e o que mantem o projeto viavel para uma equipe pequena.

Type I vs Type II: fotografia contra filme

A distincao mais consequente do SOC 2 e entre os dois tipos de relatorio, e ela determina cronograma, custo e o peso do documento na mesa de negociacao. O SOC 2 Type I avalia, numa data especifica (as of date), se os controles estao desenhados e implementados de forma adequada para atender aos criterios escolhidos. E uma fotografia: o auditor verifica que o controle existe e esta bem desenhado naquele ponto. Por isso e mais rapido de obter — assim que os controles estao implementados, voce pode fazer um Type I em semanas.

O SOC 2 Type II avalia o desenho e a efetividade operacional dos controles ao longo de um periodo de observacao, tipicamente de 3, 6 ou 12 meses. E um filme: o auditor nao pergunta apenas 'o controle existe?', mas 'ele operou de forma consistente durante toda a janela?'. Para isso ele faz testes de amostragem ao longo do periodo — por exemplo, seleciona um subconjunto de mudancas de codigo do trimestre e verifica se cada uma passou pela aprovacao exigida, ou amostra novos colaboradores e confere se o provisionamento de acesso seguiu a politica. Um controle que falhou em parte do periodo, ou cuja evidencia nao existe para toda a janela, gera uma excecao (exception) descrita no relatorio.

Na decisao de sequenciamento, o padrao mais comum para uma startup e usar o Type I como ponte. Voce implementa os controles, emite um Type I para ter algo concreto a mostrar rapido enquanto fecha deals que aceitam um relatorio inicial, e simultaneamente entra no periodo de observacao do Type II. Isso evita esperar meses sem nenhum artefato. Clientes nos EUA costumam aceitar um Type I de fornecedor jovem como medida transitoria, mas a expectativa quase universal e que o proximo ciclo entregue um Type II — e dai em diante a renovacao do Type II vira anual e continua, com periodos que se emendam para nao deixar lacunas (gaps de cobertura) entre relatorios.

O ponto que founders subestimam: o periodo de observacao do Type II nao acelera com dinheiro. Voce pode contratar o melhor auditor e a melhor plataforma, mas se o escopo pede tres meses de operacao, sao tres meses de evidencia que precisam ser acumulados de verdade. Por isso o relogio do Type II deve comecar a correr cedo — assim que os controles estao operando — para que o relatorio fique pronto quando o pipeline exigir.

Evidencia, o readiness assessment e o papel do auditor

O coracao operacional de um SOC 2 e a evidencia. Cada controle declarado na descricao do sistema precisa de prova de que existe e — no Type II — de que operou durante todo o periodo. Evidencia e o registro concreto: a configuracao que forca MFA, o log de revisao trimestral de acessos com data e responsavel, o ticket de offboarding mostrando que o acesso de um ex-colaborador foi revogado dentro do SLA interno, o pull request com aprovacao obrigatoria antes do merge, o relatorio de pentest e o registro do retest, o alerta de monitoramento e o ticket de tratamento. A licao central: desenhe os controles para gerar evidencia automaticamente. Um controle que depende de alguem lembrar de tirar um print mensal vai falhar na amostragem do Type II.

Antes de o auditor entrar, o passo de maior retorno e o readiness assessment (avaliacao de prontidao), tambem chamado de gap assessment. Aqui um parceiro de preparacao mapeia seus controles atuais contra os criterios do escopo, identifica lacunas, ajuda a implementar o que falta e valida que a evidencia esta sendo coletada do jeito que o auditor vai querer ver. Esse trabalho e independente da auditoria — e exatamente o que a Decripte faz dentro da Seguranca Normativa: estruturar controles e conformidade, conduzir o pentest que o escopo de Security frequentemente cobra, e organizar a evidencia para que voce chegue ao auditor sem surpresas. O plano gratuito de Gestao de Ameacas ajuda a estabelecer a visibilidade inicial — monitoramento e identificacao de exposicoes — que alimenta varios controles do Common Criteria.

O papel do auditor (CPA) e deliberadamente separado. Ele revisa a descricao do sistema escrita por voce, testa o desenho dos controles (Type I) e, no Type II, executa testes de operacao sobre amostras do periodo. Ao final emite a opiniao: sem ressalvas (unqualified) quando os controles atendem aos criterios; com ressalva (qualified) quando ha excecoes relevantes; e variacoes mais graves em casos extremos. A independencia exige que quem prepara a empresa nao seja quem assina o relatorio — manter esses papeis em organizacoes distintas e o que preserva a credibilidade do SOC 2 perante o cliente.

Vale calibrar expectativa sobre ferramentas. Plataformas de automacao de conformidade integram-se aos seus sistemas de nuvem, RH e codigo para coletar evidencia continuamente e mapea-la aos criterios. Elas reduzem trabalho manual, mas nao substituem o desenho correto dos controles nem o julgamento de escopo — automatizar um controle mal desenhado apenas produz evidencia consistente de algo errado. A combinacao eficiente para uma startup e: plataforma para coleta continua, parceiro de preparacao para desenho e correcao, e CPA independente para a atestacao.

Como uma startup enxuta se prepara e tira o SOC 2

O sequenciamento sensato comeca pela decisao de escopo, nao pela escolha do auditor. Defina o sistema (quais produtos, ambientes e equipes entram), os criterios (Security mais o que voce promete) e o tipo de relatorio que o pipeline exige. Essa definicao e a alavanca que mais afeta prazo e custo: um escopo amplo demais multiplica controles e evidencia; um escopo enxuto e defensavel entrega valor comercial mais rapido. Para a maioria das startups B2B o ponto de partida e Security mais Confidentiality, com Type I como ponte e Type II em sequencia.

Em seguida vem a base de controles e politicas, que se sobrepoe fortemente ao que ja seria exigido por qualquer cliente enterprise: MFA em acessos de producao e administracao, criptografia em transito e em repouso, gestao de identidade com privilegio minimo, logging e monitoramento centralizados, gestao de vulnerabilidades, backups testados, plano de resposta a incidentes, gestao de mudancas com aprovacao, gestao de fornecedores e um ciclo de desenvolvimento seguro. Frameworks como o NIST Cybersecurity Framework 2.0 e os CIS Critical Security Controls servem de mapa para nao esquecer categorias, e quem mira SOC 2 e ISO 27001 ao mesmo tempo aproveita que boa parte dos controles e comum aos dois.

Com controles implementados, inicie a coleta de evidencia e o periodo de observacao do Type II o quanto antes — o relogio so corre depois que os controles estao operando. Conduza um readiness assessment para fechar lacunas antes da auditoria, faca o pentest e corrija os achados por severidade, e so entao contrate o CPA independente para a atestacao. Tratar a sequencia nessa ordem evita o erro mais caro: chamar o auditor cedo demais, colher excecoes evitaveis e ter que refazer ciclo.

Sobre fazer interno versus terceirizar: para uma startup antes da maturidade de um time de seguranca dedicado, o modelo eficiente combina um responsavel interno (primeiro hire de seguranca ou o proprio CTO no inicio) com parceiros externos para o que exige especializacao e independencia — readiness, pentest e suporte a auditoria — e um CPA separado para assinar. E exatamente esse arranjo que a Decripte sustenta: visibilidade continua de ameacas no plano gratuito de Gestao de Ameacas, e Seguranca Normativa para conformidade, controles, pentest e monitoramento, de modo que voce chegue ao auditor com as lacunas fechadas e a evidencia organizada — sem inflar headcount e com o cronograma de seguranca acompanhando o de vendas.

Checklist prático

1. 1

   1. Defina o escopo antes de tudo

   Delimite o sistema avaliado (produtos, ambientes, equipes), escolha os Trust Services Criteria (Security e obrigatorio; adicione Confidentiality, Availability, Processing Integrity ou Privacy apenas conforme o que voce promete ao cliente) e decida Type I, Type II ou Type I como ponte para o Type II. Escopo enxuto e a maior alavanca de prazo e custo.

2. 2

   2. Implemente os controles do Common Criteria

   Cubra a base de Security (CC1 a CC9): MFA em producao e administracao, criptografia em transito e em repouso, gestao de identidade com privilegio minimo, logging e monitoramento, gestao de vulnerabilidades e mudancas, backups testados e resposta a incidentes. Use NIST CSF 2.0 e CIS Controls como mapa de cobertura.

3. 3

   3. Formalize as politicas e desenhe controles que geram evidencia

   Escreva politicas reais de seguranca, controle de acesso, mudancas, resposta a incidentes, fornecedores e desenvolvimento seguro. Desenhe cada controle para produzir prova automatica — logs, tickets, aprovacoes de pull request, registros datados de revisao de acesso —, porque o Type II avalia operacao consistente, nao intencao.

4. 4

   4. Inicie a coleta de evidencia e o periodo de observacao cedo

   Assim que os controles operam, comece a acumular evidencia e ligue o relogio do periodo de observacao do Type II (3, 6 ou 12 meses). Uma plataforma de automacao de conformidade ajuda a coletar e mapear evidencia continuamente, mas nao substitui o desenho correto dos controles.

5. 5

   5. Faca um readiness assessment e feche as lacunas

   Antes do auditor, conduza uma avaliacao de prontidao (gap assessment) contra os criterios do escopo com um parceiro de preparacao, corrija as lacunas e valide que a evidencia esta no formato que o auditor vai amostrar. Esse passo evita excecoes evitaveis no relatorio.

6. 6

   6. Realize o pentest e corrija por severidade

   O criterio Security frequentemente exige teste de penetracao. Contrate um pentest independente alinhado ao OWASP, priorize a correcao por severidade e solicite o retest. Guarde o relatorio e a evidencia de remediacao como parte do pacote de controles.

7. 7

   7. Contrate o CPA independente para a atestacao

   Selecione uma firma de CPA licenciada pela AICPA — separada de quem preparou a empresa, para preservar a independencia. O auditor revisa a descricao do sistema, testa desenho (Type I) e operacao (Type II) e emite a opiniao. Planeje a renovacao anual do Type II com periodos que se emendam para nao deixar gaps de cobertura.

Perguntas frequentes