Conformidade SOC 2 para startups: guia passo a passo

Um cliente maior gosta do teu produto, o departamento de compras envia-te um questionário de segurança e, lá pela pergunta quarenta, pede o teu relatório SOC 2. Sem ele, o negócio fica parado ou avança com condições. Este guia é para esse momento, escrito para uma startup europeia que vende a empresas maiores do que ela.

SOC 2 ou ISO 27001: qual primeiro

Os dois produzem documentos diferentes. Um relatório SOC 2 é uma atestação: um auditor independente descreve o teu sistema, testa os teus controlos face aos Trust Services Criteria e emite uma opinião, incluindo as exceções que encontrar. Não há certificado; os compradores leem o relatório. A ISO 27001 certifica um sistema de gestão de segurança da informação (SGSI). Um organismo de certificação acreditado audita-o e emite um certificado válido por três anos, com auditorias de acompanhamento pelo meio.

Decide a partir dos teus compradores. Junta os últimos dez questionários, RFPs e minutas de contrato que recebeste e anota o que cada um pede pelo nome:

• SOC 2 pedido explicitamente, muitas vezes como "SOC 2 Type II": começa pelo SOC 2. É um referencial de origem norte-americana, e os compradores norte-americanos costumam pedi-lo pelo nome.
• É pedido um certificado ISO 27001, o habitual nas compras de grandes empresas e do setor público europeus: começa pela ISO 27001.
• Nenhum dos dois: qualquer um serve, por isso escolhe o que o teu maior negócio em aberto aceitar.
• Clientes abrangidos pela NIS2 ou pelo DORA: têm de gerir a segurança dos seus fornecedores, por isso conta com cláusulas sobre notificação de incidentes e direito de auditoria, além de qualquer relatório.

A sobreposição é grande. Ambos esperam controlo de acessos, gestão de alterações, logging, resposta a incidentes, gestão de fornecedores e avaliação de riscos, por isso o mesmo conjunto de controlos de engenharia serve os dois. A ISO 27001 acrescenta um sistema de gestão (tratamento de riscos, Declaração de Aplicabilidade, auditoria interna, revisão pela gestão); um SOC 2 Tipo II acrescenta a prova de que cada controlo funcionou ao longo de todo um período. Constrói os controlos uma vez e mapeia-os para ambos. Para perceberes como isto se articula com o RGPD e a NIS2, lê o nosso guia de conformidade em cibersegurança entre jurisdições.

Âmbito: sistemas, pessoas e critérios

O âmbito é a fronteira que o auditor testa. Traça-a à volta do serviço que os teus clientes compram:

• O ambiente de produção: computação, repositórios de dados, filas e as redes entre eles.
• O pipeline que o constrói e implementa, e os repositórios Git por trás dele.
• O teu fornecedor de identidade e todas as ferramentas que dão acesso à produção.
• As pessoas com acesso à produção ou a dados de clientes, e o processo de RH que as adiciona e remove.

Deixa de fora o que não toca no serviço nem nos seus dados: o site de marketing, a wiki interna, as ferramentas de design. O teu fornecedor de cloud é uma organização subcontratada (subservice organization): com o método carve-out, o mais usado, os controlos dele ficam fora do teu relatório e tu revês o relatório SOC 2 do próprio fornecedor.

Depois escolhe os Trust Services Criteria. Segurança (os critérios comuns) está sempre incluída. As outras quatro categorias são opcionais, e cada uma acrescenta critérios que o auditor testa:

• Disponibilidade: acrescenta-a se os teus contratos têm compromissos de uptime.
• Confidencialidade: acrescenta-a se os contratos definem informação confidencial que tens de proteger e eliminar.
• Integridade do processamento: acrescenta-a se o processamento correto é o produto, como em pagamentos ou processamento salarial.
• Privacidade: sobrepõe-se muito ao que o RGPD já te exige; acrescenta-a só quando um comprador a pedir.

Tipo I versus Tipo II

Um relatório Tipo I cobre uma única data: o teu sistema está descrito com rigor e os controlos estão adequadamente desenhados? Um relatório Tipo II acrescenta se esses controlos funcionaram de forma eficaz ao longo de todo um período de observação, o que é testado com amostras de evidências recolhidas ao longo desse período.

A duração do período é acordada com o teu auditor, e alguns compradores fixam um mínimo, por isso pergunta a ambos antes de escolheres a data de início. Um Tipo I ajuda quando um negócio precisa de um documento já; caso contrário, avança diretamente para o Tipo II. Entre relatórios, os compradores pedem muitas vezes uma bridge letter: uma declaração tua de que nada de relevante mudou desde o fim do último período.

Os controlos como tarefas de engenharia

Para a maioria dos controlos, um auditor de Tipo II pede uma população, por exemplo todas as saídas de colaboradores no período ou todas as alterações integradas em produção, e testa uma amostra. Por isso, cada controlo tem de deixar um registo por omissão, e tens de conseguir apresentar a lista completa de todo o período.

SSO e MFA em todo o lado

Põe todos os sistemas dentro do âmbito atrás do teu fornecedor de identidade e obriga a MFA aí: consola da cloud, plataforma Git, CI, ferramentas de base de dados. Mantém uma ou duas contas break-glass documentadas, com um alerta em cada utilização.

Evidências: a lista de aplicações dentro do âmbito com o método de login de cada uma, a configuração que obriga a MFA, uma exportação de utilizadores com o estado de adesão à MFA e os logs de utilização das contas break-glass.

Entradas, mudanças de função e saídas

Desencadeia as alterações de acesso a partir do registo de RH: um ticket por cada entrada, mudança de função e saída, com as permissões listadas. Define um prazo de remoção de acessos que consigas cumprir sempre, por exemplo o último dia de trabalho da pessoa. Desativa primeiro a conta no fornecedor de identidade e depois revoga as chaves e tokens que vivem fora do SSO.

Evidências: a lista de RH com as entradas e saídas e, para cada pessoa da amostra, o ticket e o momento em que o acesso foi concedido ou removido.

Revisões periódicas de acessos

Com a cadência que a tua política definir, por exemplo trimestral, o responsável de cada sistema de produção revê quem tem acesso e assina. Cada remoção passa a ser um ticket.

Evidências: a lista de acessos exportada, a aprovação datada e os tickets de remoção fechados.

Gestão de alterações

Protege o ramo por omissão de todos os repositórios de produção: nada de pushes diretos, administradores incluídos; uma aprovação de alguém que não seja o autor; checks de CI obrigatórios; deploy só a partir do pipeline. Define uma via de emergência que é revista depois. É este o pipeline que a nossa prática de DevSecOps constrói.

Evidências: a configuração de proteção dos ramos e, para cada alteração da amostra, o pull request com o aprovador e o pipeline bem-sucedido.

Logging e alertas

Centraliza os logs de aplicação, de infraestrutura e de auditoria da cloud com a retenção que a tua política indicar, e encaminha os alertas de segurança (rajadas de logins falhados, alterações de privilégios, logging desligado) para a equipa de on-call.

Evidências: as regras de alerta, a configuração de retenção e uma amostra de alertas com o ticket que cada um gerou.

Backups com restauro testado

Automatiza os backups, guarda-os separados da produção e restaura um de forma agendada:

dropdb --if-exists restore_test
createdb restore_test
pg_restore --exit-on-error -d restore_test /backups/app-latest.dump
psql -d restore_test -c "SELECT count(*), max(created_at) FROM orders;"

Evidências: o histórico dos jobs de backup e um registo de cada restauro: data, duração, o que foi verificado e quem o fez.

Gestão de vulnerabilidades

Analisa dependências, imagens de contentores e hosts, e define prazos de correção por severidade, por exemplo críticas em 7 dias, altas em 30 e médias em 90. Escolhe números que vais cumprir sempre: o auditor testa contra a tua política, e cada falha precisa de uma exceção aprovada.

Evidências: os resultados das análises, os tickets com datas de abertura e fecho, e o registo de exceções.

Cifragem em trânsito e em repouso

TLS em todos os endpoints que transportam dados de clientes, incluindo os internos; cifragem em todos os repositórios de dados e backups; chaves num serviço gerido de chaves com acesso restrito. Se a tua infraestrutura está em Terraform, o código é evidência.

Evidências: exportações de configuração ou código de infraestrutura, mais uma análise TLS dos endpoints públicos.

Inventário de fornecedores

Lista todos os fornecedores que tocam em dados de clientes ou na produção: que dados, que acesso, uma classificação de risco e quando reviste pela última vez o relatório ou certificado de segurança de cada um. A tua lista de subcontratantes ao abrigo do RGPD é o ponto de partida.

Evidências: o inventário e as revisões datadas.

Plano de resposta a incidentes e exercício de simulação

Escreve um plano curto: níveis de severidade, quem lidera, como se notificam clientes e autoridades, como se preservam as evidências. Depois ensaia-o com um cenário realista, como uma chave de deploy exposta, e transforma as lacunas em tickets.

Evidências: o plano, o registo do exercício (data, participantes, cenário, conclusões) e os tickets de seguimento.

Políticas que as pessoas leem mesmo

Escreve políticas que descrevem o que fazes, com poucas páginas cada uma, e pede a todos que as aceitem ao entrar e todos os anos, a par de uma formação de sensibilização para a segurança.

Evidências: cada política com o seu responsável e data de revisão, e o registo de aceitação de cada pessoa.

Não sabes quais destes controlos já cumpres? Pede uma avaliação gratuita de preparação para SOC 2: percorremos contigo o fornecedor de identidade, os repositórios, o pipeline e os backups face aos critérios e entregamos-te uma lista de lacunas ordenada por risco de auditoria.

Recolhe evidências dos sistemas que já tens

Capturas de ecrã tiradas na semana antes do trabalho de campo são a evidência mais fraca que podes apresentar. Exporta-a de forma agendada, com data e hora, e guarda-a onde ninguém a possa alterar sem deixar rasto. Um job semanal como este produz as populações que os auditores pedem:

#!/usr/bin/env bash
set -euo pipefail
SINCE="2026-01-01"
UNTIL="2026-06-30"
OUT="evidence/$(date +%F)"
mkdir -p "$OUT"

# Every change that reached the default branch in the window
git -C /srv/repos/app log main --first-parent --since="$SINCE" --until="$UNTIL" --format='%H|%an|%cI|%s' > "$OUT/changes-main.txt"

# Who holds which role in the production cluster
kubectl get rolebindings,clusterrolebindings -A -o wide > "$OUT/k8s-bindings.txt"

# Database logins and superusers
psql -d app -At -c "SELECT rolname, rolsuper, rolvaliduntil FROM pg_roles WHERE rolcanlogin;" > "$OUT/db-roles.txt"

# Fingerprint the snapshot
(cd "$OUT" && sha256sum ./*.txt > SHA256SUMS)

O log do Git é a população de alterações. As plataformas Git alojadas expõem as regras de proteção dos ramos, as aprovações dos pull requests e os resultados dos pipelines através das suas APIs REST: liga cada commit ao seu pull request e tens, por alteração, o autor, o aprovador e o estado do pipeline, que é exatamente o que vai ser amostrado. Acrescenta a exportação de utilizadores e MFA do teu fornecedor de identidade e escreve tudo num armazenamento de objetos com versionamento ou bloqueio de retenção. As plataformas de automação de conformidade fazem o mesmo através de integrações; se compensam face a meia dúzia de scripts depende de quantos sistemas tens. Para a parte do cluster, lê como automatizar as evidências de conformidade em Kubernetes.

Um plano de preparação de 12 semanas

Semanas 1-2: decidir e delimitar o âmbito

• Uma nota com a decisão sobre o referencial, baseada nos questionários que juntaste.
• Um diagrama da fronteira do sistema e um inventário dos sistemas, repositórios de dados e pessoas dentro do âmbito.
• A seleção de critérios e um registo de lacunas, uma linha por controlo.
• Uma lista curta de auditores e uma primeira conversa sobre a duração do período e as datas.

Semanas 3-4: identidade

• SSO e MFA obrigatória em todos os sistemas dentro do âmbito, com as contas break-glass documentadas.
• Tickets de entradas e saídas desencadeados pelos RH e um runbook de saída.
• A primeira revisão de acessos, concluída e assinada.

Semanas 5-6: alterações e build

• Proteção de ramos em todos os repositórios de produção, administradores incluídos.
• Deploys só a partir da CI e um procedimento escrito para alterações de emergência.

Semanas 7-8: operações

• Logging centralizado, com os alertas de segurança encaminhados para a equipa de on-call.
• Análise de vulnerabilidades ativa, com os prazos por severidade no sistema de tickets.
• Cifragem verificada, backups a correr e o primeiro teste de restauro registado.

Semanas 9-10: políticas, fornecedores e risco

• Um conjunto de políticas que corresponde ao que agora fazes, aceite por todos.
• O inventário de fornecedores, uma avaliação de riscos e o plano de resposta a incidentes.

Semanas 11-12: ensaiar

• O exercício de simulação realizado e os jobs de evidências a correr conforme o agendado.
• Uma revisão interna de preparação: escolhe amostras como um auditor faria e corrige tudo o que não consigas apresentar.
• A data de início do período de observação acordada com o auditor.

Depois abre-se o período de observação: nada de novo para construir, só controlos para executar a tempo. Põe cada controlo recorrente num calendário partilhado com um responsável (revisões de acessos, testes de restauro, revisões de fornecedores) e verifica a pasta de evidências todos os meses, para seres tu, e não o auditor, a encontrar uma revisão esquecida.

Quanto custa e como estimar

O custo do primeiro ano é a soma de quatro rubricas, e podes estimar cada uma com os teus próprios números:

• Honorários do auditor: pede orçamentos sobre o mesmo âmbito escrito, os mesmos critérios, o mesmo tipo de relatório e o mesmo período, para comparares o que é comparável.
• Ferramentas: uma plataforma de automação de conformidade ou os teus próprios scripts, mais o que costuma ficar esquecido: o plano superior que algumas ferramentas exigem antes de oferecerem SSO, a gestão de dispositivos para os portáteis e os scanners.
• Trabalho para fechar lacunas: estima em horas cada linha do teu registo de lacunas, acrescenta a automação de evidências e multiplica por um custo horário com encargos incluídos.
• Manutenção: horas semanais para os controlos recorrentes e as entrevistas com o auditor, multiplicadas pelas semanas do período de observação e pelo mesmo custo horário.

Armadilhas que atrasam uma primeira auditoria

Políticas escritas para uma empresa imaginária. Os modelos descarregados descrevem uma equipa de segurança e um comité de alterações que não tens. O auditor testa o que a política diz, por isso cada frase que não consegues sustentar com evidências torna-se uma exceção. Escreve o que fazes de facto e depois melhora-o.

Controlos que só existem na semana antes da auditoria. Um Tipo II testa o período inteiro. Uma revisão de acessos feita uma única vez, na véspera do trabalho de campo, é uma amostra das várias que o período exigia. Só começa a contar o tempo quando os controlos funcionarem sozinhos.

Meter tudo no âmbito. Cada sistema dentro do âmbito precisa de revisões de acessos, logging e evidências de alterações. Acrescentar sistemas que não interessam a nenhum comprador multiplica o trabalho.

Pede uma avaliação gratuita de preparação para SOC 2

Se um cliente te pediu um relatório SOC 2 ou um certificado ISO 27001, a nossa equipa de cibersegurança analisa contigo onde estás, sem custos. A avaliação cobre:

• Referencial e âmbito: de que relatório os teus compradores precisam e a fronteira mais pequena que os satisfaz.
• Uma lista de lacunas controlo a controlo em identidade, gestão de alterações, logging, backups e gestão de vulnerabilidades, com as evidências que cada controlo produz hoje.
• Um plano de preparação à medida da tua equipa, que indica que evidências podem ser recolhidas automaticamente.

Pede a tua avaliação gratuita de preparação para SOC 2 e recebe por escrito uma lista de lacunas e próximos passos, sem compromisso.