SOC 2 e Gestão de Ativos: as Evidências que o Auditor Vai Pedir (CC6.1, Type I vs Type II)

Empresas brasileiras que vendem tecnologia ou serviços para fora — SaaS com clientes nos EUA, BPOs que processam dados de multinacionais, fintechs integradas a parceiros globais — conhecem a cena: o contrato está praticamente fechado quando o time de procurement do cliente envia o questionário de segurança e pergunta pelo relatório SOC 2. A partir daí, o cronograma comercial passa a depender de um exame de auditoria. E um dos primeiros itens da lista de solicitações (a famosa PBC list — "provided by client") é invariavelmente o inventário de ativos: a lista do hardware, software e infraestrutura que sustenta o serviço examinado. Preparar essa base com antecedência — idealmente com um inventário de ativos de TI conciliado entre o físico, o lógico e o contábil — encurta meses de exame.

Vale fixar o vocabulário correto, porque ele protege a sua empresa de fornecedores que prometem o impossível: SOC 2 não é certificação — é um relatório de atestação (attestation report) emitido exclusivamente por firma de auditoria licenciada (CPA), sob as normas do AICPA. A CPCON não emite relatórios SOC 2 nem certifica controles — quem atesta é a firma de auditoria do seu cliente ou a contratada por você. O que entregamos, com 30 anos e mais de 4.500 projetos de inventário e auditoria de ativos, é a evidência de campo sobre os ativos: o inventário físico, a atribuição e a trilha de baixas que o auditor vai testar.

Onde os ativos entram nos Trust Services Criteria

Os Trust Services Criteria (TSC) organizam o exame em cinco categorias: segurança (obrigatória, com os critérios comuns CC1 a CC9), disponibilidade, integridade de processamento, confidencialidade e privacidade. A gestão de ativos não tem um capítulo próprio — ela permeia os critérios comuns da série CC6 (acesso lógico e físico) e aparece nos pontos de foco que os auditores usam para desenhar os testes.

A leitura conjunta é clara: o inventário é a premissa dos testes. O auditor não consegue avaliar se o acesso lógico é restrito "aos ativos protegidos" sem saber quais são os ativos; não consegue testar descarte seguro sem a lista das baixas do período; não consegue avaliar movimentação sem saber o que existe e onde deveria estar.

Inventário como base do escopo (system description)

Todo relatório SOC 2 contém a "descrição do sistema" (system description), redigida pela empresa examinada: quais serviços, infraestrutura, software, pessoas, procedimentos e dados compõem o sistema que será examinado. É o inventário que delimita essa fronteira. Subestimar o escopo (esquecer servidores legados, ambientes de homologação que recebem dados reais, notebooks de suporte) gera dois riscos: o auditor encontra ativos não declarados durante os testes — minando a confiança em toda a descrição — ou o relatório sai com escopo furado e o cliente final percebe na due diligence.

• Comece pelo inventário físico validado: o que existe de verdade, onde está, quem usa — incluindo o que a ferramenta de discovery não enxerga (equipamento desligado, em estoque, sem agente).
• Concilie com o lógico (discovery, MDM, console de EDR) e com o contábil/CMDB: cada divergência é um furo de escopo em potencial.
• Classifique o que entra no sistema examinado e o que fica fora — com critério documentado, porque o auditor pergunta pelos dois lados da fronteira.
• Congele uma linha de base datada: ela ancora a system description e os testes de amostragem do período.

As evidências que o auditor tipicamente solicita

A lista varia por firma e por escopo, mas o bloco de gestão de ativos da PBC list costuma conter:

• Inventário completo de ativos (hardware, software, infraestrutura em nuvem) com data de atualização, owner e classificação — exportado do sistema de gestão de ativos ou CMDB.
• Atribuição por dispositivo: qual colaborador detém qual notebook/celular corporativo, com termo de responsabilidade ou registro equivalente.
• Amostra de admissões e desligamentos do período: evidência de entrega do equipamento no onboarding e de devolução no offboarding (data, estado, assinatura).
• Baixas documentadas: autorização da baixa, certificado de sanitização ou destruição de mídia, destino final (doação, venda, descarte ambiental) — encadeados por ativo.
• Evidência de verificação periódica: relatório de inventário físico ou contagem cíclica do período, com divergências e plano de tratamento.
• Política de gestão de ativos aprovada e comunicada (aquisição, uso aceitável, movimentação, devolução, descarte).

Repare no padrão: o auditor quase nunca pede "um documento" — pede a trilha. A baixa sem certificado de sanitização reprova no CC6.5; o desligamento sem registro de devolução reprova no CC6.1/CC6.7; o inventário sem verificação periódica vira "controle não operante". Empresas que tratam o parque de TI junto com o imobilizado têm vantagem aqui: a disciplina de eliminar ativos fantasmas e documentar baixas já produz metade da evidência.

Type I vs Type II: a diferença é a continuidade do inventário

A distinção entre os dois tipos de relatório muda completamente o esforço sobre o inventário:

É por isso que "arrumar o inventário na véspera" funciona (mal) para um Type I e não funciona para o Type II: no Type II, o auditor seleciona eventos espalhados pelo período — uma compra de fevereiro, um desligamento de junho, uma baixa de setembro — e cobra a evidência de cada um. Sem processo contínuo, as lacunas aparecem como exceções no relatório, visíveis para todo cliente que o ler.

Como empresas brasileiras caem em SOC 2 (e por onde começar)

O gatilho raramente é regulatório — é comercial. Os caminhos mais comuns: o cliente americano exige SOC 2 Type II como condição de contrato ou renovação; o parceiro de integração (marketplace, plataforma de pagamentos) exige dos participantes; o investidor pede na due diligence; ou a empresa decide antecipar-se para destravar o funil enterprise. Em todos os casos, a sequência prática é a mesma: definir escopo, fechar os gaps de controle e só então contratar a firma de auditoria. Para quem também atende requisitos de ISO 27001 — frequentemente exigidos em paralelo —, há forte sobreposição: o mesmo inventário de ativos com owners e ciclo de vida alimenta o controle A.5.9 da ISO 27001 e os critérios CC6 do SOC 2.