SOC 2

SOC 2 é um relatório independente de um auditor sobre como uma organização prestadora de serviços protege os dados e os sistemas que opera para seus clientes. A estrutura vem do American Institute of Certified Public Accountants (AICPA), e o relatório em si é emitido por uma firma de CPA licenciada. SOC significa System and Organization Controls, portanto, apesar da sigla parecida, não tem relação com um centro de operações de segurança.

A régua são os Critérios de Serviços de Confiança (Trust Services Criteria): segurança, disponibilidade, integridade do processamento, confidencialidade e privacidade. A segurança sempre entra, e a organização escolhe quais dos outros quatro combinam com o serviço que vende. O auditor então examina a descrição do sistema feita pela administração e os controles que sustentam os critérios, e emite uma opinião.

O SOC 2 não é lei nem certificado. Ninguém é obrigado a tê-lo, e o auditor não dá nota de aprovação: o relatório diz se os controles atenderam aos critérios e lista as exceções encontradas. Os compradores o pedem porque ele oferece uma visão externa da segurança de dados do fornecedor que um questionário não oferece.

O relatório SOC 2 é o fim de um processo, não o processo em si. A auditoria é curta perto da preparação, e a maior parte do trabalho acontece antes de o auditor chegar:

1. 1

   Definir escopo e critérios

   Decida quais serviços, sistemas e locais entram e quais categorias além de Security incluir.

2. 2

   Fazer uma avaliação prévia

   Compare os controles atuais com os critérios e liste as lacunas antes que um auditor as encontre.

3. 3

   Operar e registrar

   Feche as lacunas, depois execute os controles no dia a dia e guarde os registros: chamados, logs, revisões de acesso, aprovações.

4. 4

   Passar pela auditoria

   Uma firma de CPA independente revisa a descrição do sistema e testa os controles em relação aos critérios.

5. 5

   Receber e compartilhar o relatório

   O relatório traz a opinião do auditor, costuma ser compartilhado com clientes sob NDA e é renovado em ciclos regulares, em geral a cada ano.

A segurança é obrigatória e forma os critérios comuns: acesso, gestão de mudanças, avaliação de riscos, monitoramento e resposta a incidentes. Os outros quatro entram apenas quando o serviço faz promessas sobre eles:

O SOC 2 pede que a organização mostre quem pode acessar os dados dos clientes, como esse acesso é protegido e como as mudanças nos sistemas são registradas. O Anexet não é uma ferramenta de auditoria, mas seu console guarda vários desses registros: os privilégios são definidos por grupo de usuários, salvar as configurações do Administrator Console pode exigir uma senha adicional, e as sessões do console encerram automaticamente após um tempo definido, e o Journal registra as ações dos administradores. Os eventos também podem ser enviados a um SIEM para monitoramento central.

1 / 3

• 
• 
• 

O relatório Type I descreve os controles e traz a opinião do auditor sobre se eles estão adequadamente desenhados em um único momento. O Type II cobre um período, em geral de alguns meses a um ano, e acrescenta os testes do auditor sobre se os controles realmente funcionaram de forma eficaz durante todo esse tempo.

Para o comprador, o Type II pesa mais: um controle que existe não é o mesmo que um que funcionou toda semana. Muitos fornecedores começam pelo Type I para ter algo a mostrar e depois passam ao Type II. Os clientes também pedem uma bridge letter, uma breve declaração da administração sobre o tempo entre o fim do período e hoje. É uma declaração do próprio fornecedor, não uma auditoria.

O SOC 1 trata de controles relevantes para os relatórios financeiros do cliente, o SOC 2 dos critérios de serviços de confiança, e o SOC 3 é um resumo curto de uso geral do mesmo tipo de trabalho do SOC 2, sem os testes detalhados, por isso pode ser publicado.

A ISO/IEC 27001 é o outro documento que os compradores pedem. É a certificação de um sistema de gestão de segurança da informação (ISMS) por um organismo acreditado, enquanto o SOC 2 é um relatório de atestação sobre controles que a própria organização descreve. Um não substitui o outro, mas um único conjunto de evidências mantido pela gestão de conformidade pode servir aos dois.

A maior parte dos problemas vem de tratar o SOC 2 como um selo, e não como um modo de operar. Clientes cuidadosos leem escopo, período e exceções antes da opinião, porque as lacunas de um fornecedor viram também o seu risco de conformidade. Os padrões se repetem:

• Chamar uma empresa de “certificada SOC 2” quando não há certificado, só um relatório
• Definir um escopo tão estreito que o relatório deixa de fora o produto que o cliente realmente usa
• Tentar reconstruir evidências depois do fim do período, quando o teste Type II cobre o período inteiro
• Ler apenas a opinião e pular as exceções e os controles que o próprio cliente deve executar
• Achar que o critério de Privacidade prova conformidade com uma lei de privacidade como a LGPD

Comece pelo que os clientes realmente pedem, não pelos critérios. Escolha como escopo o serviço que eles compram, comece por Security e inclua as outras categorias só quando um cliente precisar. Depois faça uma avaliação prévia e dê aos controles tempo suficiente para deixar registro antes de o período de auditoria começar.

Deixe os sistemas gerarem a evidência como subproduto do trabalho normal: listas de acesso, logs de mudanças e relatórios de segurança agendados, em vez de capturas de tela reunidas às pressas no final. Um relatório barato de renovar é o que continua sendo renovado.