Um relatório SOC 2 é escrito por uma firma de CPA licenciada, não por você nem por nós. O que o seu time de engenharia deve a essa firma é evidência de que quatro coisas funcionam e continuam funcionando. São elas: quem consegue entrar, como uma mudança chega à produção, o que é registrado e vigiado, e como a infraestrutura é definida e alterada. Nós construímos e operamos esses controles. Não os auditamos nem os certificamos. Um fornecedor pode ajudar você a se preparar, e só uma firma de CPA pode emitir o relatório.
Para dar a medida do que fizemos: numa plataforma SaaS de análise de portfólios, roda em cada merge request uma verificação de vulnerabilidades orientada a SOC 2, com exceções que expiram. Os segredos ficam num cofre gerenciado. Isso é um controle, não um relatório. Dizemos “orientada a SOC 2”, não “certificada”, e vou manter essa redação.
O que é um SOC 2 e quem o emite?
SOC significa System and Organization Controls. O AICPA descreve a família SOC como serviços que os CPAs podem prestar sobre os controles de uma organização de serviços. Um SOC 2 avalia esses controles contra os Trust Services Criteria do AICPA, que cobrem segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Um relatório pode cobrir uma categoria ou várias.
Há dois tipos de relatório. Em resumo, o Tipo I olha se os seus controles estão bem desenhados em uma data. O Tipo II olha se eles funcionaram durante um período. O Tipo II exige que a sua evidência exista durante todo o período, então os controles precisam estar rodando antes de você escolher o auditor, e essa é a parte do time de engenharia. O que construímos para essa parte está na nossa página de engenharia SOC 2.
O que uma auditoria pergunta sobre acessos?
Quem chega à produção e quando isso deixou de ser verdade. Na prática:
- Login único e autenticação multifator em todo sistema que toca produção ou dados de clientes.
- Privilégio mínimo: cada pessoa tem o acesso que o papel dela exige e nada além.
- Uma revisão periódica de quem tem acesso, que você consiga mostrar.
- O acesso é retirado quando alguém sai, com data.
Como trabalhamos: os engenheiros usam as suas próprias contas e identidades, com SSO, MFA e privilégio mínimo, e esses acessos são revogados quando o trabalho termina. Fazemos uma verificação de antecedentes de cada engenheiro antes da alocação e preenchemos o seu questionário de segurança ou avaliação de fornecedores, se você pedir.
Um teste que dá para fazer hoje: escolha uma pessoa que saiu nos últimos 90 dias e pergunte se você consegue mostrar quando cada acesso dela terminou. Se a resposta leva uma tarde, a amostra de um auditor vai levar mais.
O que uma auditoria pergunta sobre gestão de mudanças?
Que toda mudança na produção seja revisada, testada e rastreável, e que ninguém publique por fora do processo. O auditor amostra mudanças e pede o rastro de cada uma.
O nosso é assim. Um pull request com aprovador identificado. Um gate de CI que roda testes, uma varredura de segredos e uma checagem de vulnerabilidades. Um release cortado por tag e publicado pelo digest da imagem, de modo que o que roda é exatamente o que foi testado. No pipeline de promoção de um cliente de análise de portfólios, construído sobre Kargo e Argo CD, a produção espera um soak de 1 hora e portões de verificação. Os portões são checagens de fumaça na borda, de reinício e prontidão de pods e um controle da proporção de erros HTTP 5xx. As migrações de banco tiram antes um snapshot automático. E o rollback é uma repromoção que foi ensaiada em desenvolvimento.
Um teste: abra as suas últimas cinco mudanças em produção. Cada uma deveria ter um pull request com aprovador, uma execução do pipeline e o identificador do que foi publicado. A mudança sem rastro é a que o auditor vai achar.
O que uma auditoria pergunta sobre logs e monitoramento?
Que você saiba quando algo está errado e consiga mostrar o que fez. Um alerta que nunca disparou é um palpite. Numa plataforma SaaS de análise de portfólios cada alerta foi testado até disparar, e a produção saiu de nenhuma regra de alerta para 275. A mesma ideia está no nosso pacote de SRE e observabilidade: métricas, logs e traces conectados, 3 SLOs definidos, alertas testados até disparar e um runbook.
O que o auditor vai querer ver é entediante: a definição do alerta, a prova de que ele disparou, o ticket ou registro do incidente e o runbook que foi seguido. Decida quem pode ler e alterar os logs, e guarde essa evidência também.
O que uma auditoria pergunta sobre infraestrutura como código?
Que a infraestrutura esteja definida em código, seja alterada com revisão e ninguém a edite à mão num console. Assim toda mudança de infraestrutura tem um diff, um aprovador e uma data, que é exatamente o que a amostra pede.
No nosso trabalho, a infraestrutura é código com OpenTofu ou Terraform e estado criptografado, o plan é lido antes de aplicar e mudanças destrutivas esbarram num freio antes de rodar. Numa plataforma SaaS de análise de portfólios, as mudanças passam por Terraform e OpenTofu com Atlantis, que roda o plan no pull request. CI/CD e infraestrutura como código em duas semanas percorre a configuração, e o que é DevOps dá o quadro geral.
O que um parceiro de engenharia não pode fazer por você?
A parte que não é engenharia. Políticas, avaliação de riscos, verificações de RH, revisão de fornecedores e a escolha do auditor são suas. Não oferecemos plantão 24x7, então a resposta a incidentes que um auditor testa é a do seu próprio time, com os alertas e runbooks que deixamos. E nenhum pacote da nossa lista de preços deixa você em conformidade. O pacote de CI/CD e IaC (US$ 4.000 por 2 semanas) constrói a trava local antes do push, o estado, o freio de plan e o deploy por digest. O pacote SRE / Observability Foundations (US$ 5.000 por 2 semanas) constrói os alertas e o runbook. Eles produzem a evidência. Se ela basta ou não, quem decide é a firma de CPA.
Por hora, um Sênior custa US$ 45 a 50 e um Líder ou Arquiteto, US$ 55 a 60. Veja a página de preços e o artigo sobre Argo CD e Kargo para entender como funcionam os portões de promoção.
Por onde começar?
Escolha um de dois exercícios de 30 minutos. Liste todas as pessoas com acesso à produção hoje e compare com a lista do RH. Ou pegue as suas últimas cinco mudanças em produção e confira se cada uma tem aprovador, uma execução do pipeline e um identificador do que foi publicado. O que for mais difícil de responder é o seu primeiro controle.
Fontes
- AICPA & CIMA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022): a página descreve os critérios de segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. O documento exige uma conta gratuita do AICPA, então cito a descrição e não o texto dos critérios. Consultado em 9 de outubro de 2026 (sha256 ea5a9da2…).
- AICPA & CIMA, System and Organization Controls (SOC) suite of services: os serviços SOC são ofertas que os CPAs podem prestar. Consultado em 9 de outubro de 2026 (sha256 7c990af6…).
- Nosso caso: pipeline de releases fintech, para a verificação de vulnerabilidades, o pipeline de promoção, os alertas e o fluxo com Atlantis. O resumo de Tipo I e Tipo II é meu e não vem dessas páginas.