SOC 2 e Controle de Acesso: Exigências do Trusted Service Criteria

SOC 2 e Controle de Acesso: Exigências do Trusted Service Criteria

Entenda as exigências do Trust Service Criteria do SOC 2 em gestão de identidade e acesso, quais evidências o auditor pede e como atender ao CC6 e CC7.


Resumo:

  • O SOC 2 é um framework de atestação do AICPA que avalia os controles de segurança, disponibilidade, integridade, confidencialidade e privacidade de organizações de serviço, sendo um pré-requisito para empresas brasileiras que vendem para clientes americanos.
  • O SOC 2 Type II exige que os controles funcionem continuamente ao longo de um período de 6 a 12 meses, com evidências de cada etapa.
  • O critério CC6, de controles de acesso lógico, concentra aproximadamente 60% dos achados em auditorias SOC 2 e é onde a maioria das empresas enfrenta mais dificuldades. 
  • Identidades não humanas, como APIs, bots e service accounts, também estão no escopo do CC6 e precisam de controles documentados, revisão periódica e permissões mínimas necessárias.
  • Uma estratégia única de gestão de identidade atende simultaneamente ao SOC 2, à ISO 27001 e ao BACEN, pois os três frameworks exigem essencialmente os mesmos controles de acesso com formatos de evidência diferentes.

Para empresas de tecnologia que vendem para clientes americanos ou globais, o SOC 2 deixou de ser um diferencial e se tornou pré-requisito. Mas o que muitas empresas descobrem durante o processo de certificação é que o critério que concentra a maior parte dos achados de auditoria é exatamente o de controle de acesso lógico, o CC6.

Este artigo explica o que o Trust Service Criteria do SOC 2 exige em termos de gestão de identidade e acesso, quais evidências o auditor vai solicitar e como implementar os controles de forma que a conformidade exista continuamente.

O que é SOC 2 e por que importa para empresas brasileiras

SOC 2 (System and Organization Controls 2) é um framework de conformidade desenvolvido pelo AICPA (American Institute of Certified Public Accountants) que avalia os controles de uma organização de serviços em relação à segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade dos dados que processa.

O SOC 2 resulta em um relatório de atestação emitido por um auditor independente. Esse relatório é o que clientes americanos, investidores e parceiros corporativos solicitam antes de fechar contratos com empresas de tecnologia que processam dados sensíveis.

Para empresas brasileiras de SaaS, fintechs e provedores de tecnologia com clientes ou investidores nos Estados Unidos, o SOC 2 se tornou uma exigência contratual frequente. Ter o relatório reduz a fricção em negociações, acelera processos de due diligence e demonstra maturidade em segurança da informação.

SOC 2 Tipo 1 ou Tipo 2: qual a diferença?

SOC 2 Tipo 1: avalia se os controles estão adequadamente desenhados em um momento específico, demonstrando que tais controles existem e foram projetados corretamente. Mais rápido e menos custoso de obter, mas geralmente é aceito apenas temporariamente enquanto a empresa busca a certificação tipo 2.

SOC 2 Tipo 2: avalia se os controles funcionaram efetivamente ao longo de um período de auditoria, geralmente de 6 a 12 meses. É o padrão que a maioria dos clientes americanos exige. Exige que os controles operem continuamente, com evidências do período auditado, com logs, relatórios de revisão e registros de provisionamento e revogação.

Quando uma empresa brasileira precisa de SOC 2?

  • Em vendas para clientes corporativos americanos, que exigem o relatório antes de assinar contrato.
  • Nos processos de captação com investidores que conduzem due diligence de segurança.
  • Ao processar dados sensíveis de usuários americanos, em que é preciso demonstrar conformidade.
  • Em disputas com empresas que já têm SOC 2 e o usam como diferencial em negociações.
  • Caso planeje expandir para o mercado americano e quer eliminar fricção regulatória antecipadamente.

Os 5 Trust Service Criteria e qual se aplica à sua empresa

O SOC 2 é estruturado em torno de cinco Trust Service Criteria (TSC). Apenas o critério de Segurança é obrigatório,  enquanto os demais são incluídos de acordo com o escopo definido pela empresa e pelo auditor.

CritérioObrigatoriedadeO que avaliaQuando incluir
Segurança (CC)Obrigatório para todosControles de acesso, monitoramento, criptografia e resposta a incidentesTodas as empresas que buscam SOC 2
Disponibilidade (A)OpcionalSLA, redundância e planos de continuidade de negócios documentadosSaaS com compromissos de uptime com clientes
Integridade de Processamento (PI)OpcionalGarantia de que o processamento é completo, válido e autorizadoEmpresas de processamento financeiro ou transacional
Confidencialidade (C)OpcionalProteção de dados identificados como confidenciais nos contratosEmpresas que processam dados sensíveis de clientes
Privacidade (P)OpcionalColeta, uso, retenção e descarte de dados pessoais alinhados à políticaEmpresas com processamento intensivo de dados pessoais

Muitas empresas de SaaS incluem Segurança e Disponibilidade como o escopo mínimo. Empresas que processam dados financeiros ou de saúde frequentemente adicionam Confidencialidade e Privacidade. A definição do escopo impacta diretamente o custo e o tempo da auditoria, e deve ser feita com cuidado, pois ampliar o escopo depois exige uma nova auditoria.

CC6: Controles de Acesso Lógico e Físico, o Coração da Identidade no SOC 2

O CC6 é o subcritério do TSC de Segurança dedicado a controles de acesso lógico e físico. É o critério que concentra a maior parte dos achados em auditorias SOC 2, aproximadamente 60% das observações registradas em relatórios SOC 2 estão relacionadas ao CC6, segundo análises do setor. O controle de acesso envolve processos operacionais contínuos que dependem de disciplina, automação e evidência.

O que o CC6 exige

Os principais requisitos do CC6 em termos de gestão de identidade e acesso são:

  • Acesso a sistemas e dados restrito a usuários autorizados, com base em necessidade operacional documentada.
  • Autenticação forte implementada, especialmente para sistemas críticos e acessos remotos.
  • Revisão periódica dos direitos de acesso com evidência de que cada revisão foi realizada com análise real.
  • Processo documentado de provisionamento: como os acessos são concedidos, com qual aprovação e justificativa.
  • Processo documentado de revogação: como os acessos são removidos no desligamento ou na mudança de função.
  • Controles sobre acessos privilegiados: contas administrativas com monitoramento e registro de atividade.
  • Segregação de funções em operações críticas, a fim de impedir que uma mesma pessoa autorize e execute ações sensíveis.

Provisionamento, revisão e revogação como evidência auditável

Para o SOC 2 Tipo 2, cada um desses processos precisa deixar um rastro que confirme sua operação durante o período auditado. Isso significa que cada concessão de acesso precisa ter registro de quem aprovou, quando e com qual justificativa. Cada revisão periódica precisa ter evidência de que foi realizada com análise individual. Cada revogação precisa ter log com data e hora.

Empresas que dependem de processos manuais para gestão de acesso frequentemente chegam à auditoria sem evidências suficientes para o período completo. O relatório SOC 2 Tipo 2 cobre de 6 a 12 meses e reconstruir o histórico de acessos manualmente para esse período é um esforço significativo que pode ser evitado com automação contínua.

Gestão de acessos privilegiados no contexto SOC 2

Contas com permissões administrativas, como  acesso a servidores de produção, bancos de dados, sistemas de pagamento, recebem atenção especial no CC6. O auditor vai verificar se há controles adicionais sobre quem pode usar essas contas, se os acessos são aprovados formalmente antes de cada uso e se há registro de sessão para ações críticas.

O modelo de acesso just-in-time, onde privilégios são concedidos temporariamente com prazo definido e revogados automaticamente, é o que mais se alinha ao que o CC6 espera para acessos privilegiados. Credenciais permanentes de administrador sem registro de uso são um dos achados mais frequentes em auditorias SOC 2.

Identidades não-humanas: APIs e service accounts no escopo do CC6

O CC6 não se limita a identidades humanas: APIs, bots, integrações e service accounts são igualmente escopo da auditoria. O auditor vai verificar se essas contas têm permissões mínimas necessárias, se são revisadas periodicamente e se há controles sobre as credenciais.

Contas de serviço com privilégios de administrador concedidos para resolver um problema pontual e nunca revisados, ou chaves de API ativas de integrações que foram descontinuadas estão entre os principais achados. Para o auditor SOC 2, cada uma dessas contas é uma identidade que precisa de controle documentado.

CC7: Monitoramento de Sistemas e sua Relação com Identidade

O CC7 trata das operações do sistema, como detecção, resposta e monitoramento contínuo. Em termos de identidade e acesso, ele se conecta diretamente com o CC6, monitorando o que cada identidade faz depois que o acesso é concedido.

O que o CC7 exige em termos de rastreabilidade

  • Monitoramento contínuo de sistemas para detecção de comportamentos anômalos.
  • Alertas configurados para acessos fora do padrão: horários incomuns, volumes elevados, tentativas de acesso a sistemas restritos.
  • Processo documentado de resposta a incidentes de segurança relacionados ao acesso.
  • Revisão periódica de logs de acesso para identificar atividades suspeitas.

Como trilha de auditoria e logs de acesso atendem ao CC7

A trilha de auditoria que atende ao CC6 (quem acessou, o que e quando) é o mesmo conjunto de dados que o CC7 usa para monitoramento. Uma plataforma de gestão de identidade que centraliza logs de acesso de múltiplos sistemas em uma visão única gera evidências para os dois critérios simultaneamente, o que reduz significativamente o esforço de preparação para o período de auditoria.

O que o Auditor SOC 2 Verifica em Termos de Identidade e Acesso

A diferença entre um relatório sem ressalvas e um relatório com achados frequentemente está na qualidade das evidências apresentadas na auditoria.

Evidências que precisam existir antes da auditoria

  • Lista completa de usuários ativos com seus respectivos perfis de acesso e data da última revisão.
  • Registros de provisionamento: quem concedeu cada acesso, quando e com qual aprovação.
  • Registros de revisão periódica: data, responsável, resultado (aprovação ou revogação) e justificativa.
  • Registros de revogação: data e hora de encerramento de acesso para cada desligamento ou mudança de função.
  • Inventário de contas privilegiadas com histórico de uso e aprovações.
  • Inventário de identidades não-humanas com permissões documentadas e data da última revisão.
  • Logs de acesso a sistemas críticos cobrindo todo o período de auditoria.

Os erros mais comuns que geram achados no CC6

  1. Aprovação em massa nas revisões periódicas

Quando os responsáveis aprovam dezenas de acessos em poucos minutos sem análise individual, o auditor identifica fadiga de revisão, gerando um achado. 

  1. Contas de ex-colaboradores ainda ativas

Qualquer conta ativa de usuário que não consta mais no sistema de RH é um achado imediato. O processo de revogação precisa ser documentado e automatizado.

  1. Service accounts sem revisão

Contas de serviço com permissões excessivas ou sem responsável identificado são um dos achados mais frequentes.

  1. Evidências incompletas para o período

O SOC 2 Tipo 2 cobre de 6 a 12 meses. Se os controles só foram formalizados nos últimos dois meses antes da auditoria, o relatório vai refletir isso com ressalvas.

Como gerar evidências contínuas 

A única forma de chegar a uma auditoria SOC 2 Type II sem correr contra o tempo é tratar a conformidade como uma operação contínua desde o primeiro dia do período auditado. 

Empresas que automatizam o ciclo de vida de identidades chegam ao início da auditoria com o histórico completo já organizado. Empresas que dependem de processos manuais chegam ao início da auditoria com semanas de trabalho de levantamento de evidências pela frente.

SOC 2, ISO 27001 e BACEN: Como os Três se Conectam em Gestão de Identidade

Para empresas brasileiras de tecnologia que atendem ao mercado financeiro, a sobreposição entre SOC 2, ISO 27001 e BACEN em termos de controle de identidade é significativa. Os três frameworks exigem essencialmente os mesmos controles, com escopos, ciclos de auditoria e formatos de evidência diferentes.

O que cada framework exige de forma específica

FrameworkO que exige em identidadeCiclo de auditoriaEvidência necessária
SOC 2 (CC6 e CC7)Controle de acesso lógico, revisão de permissões, monitoramento e trilha de auditoriaPeríodo de auditoria (6–12 meses) com operação contínua dos controlesEvidências de que os controles funcionaram ao longo do período
ISO 27001 (A.5.15–A.5.18)Política de acesso, provisionamento, credenciais e revisão de direitosAuditorias anuais de certificação e manutenção por organismo acreditadoPolítica documentada, registros de revisão e evidências de implementação contínua
BACEN (CMN 4.893 e 5.274)Controle de acesso a sistemas críticos, gestão de terceiros e revogação no offboardingVisitas de supervisão do BACEN a qualquer momentoLogs de acesso, relatórios de revisão e registros de offboarding com data e responsável

Como uma estratégia única de IDM atende aos três simultaneamente

A sobreposição entre os três frameworks significa que uma empresa que implementa gestão de identidade de forma estruturada, com ciclo de vida automatizado, revisão periódica com evidência e trilha de auditoria centralizada, naturalmente gera os registros necessários para SOC 2, ISO 27001 e BACEN ao mesmo tempo.

O que muda entre os frameworks é o formato e o destinatário da evidência. Para o auditor SOC 2, é o relatório de período. Para o certificador ISO 27001, é necessário o registro de implementação contínua. Para o BACEN, é o log exportável em visita de supervisão. Uma plataforma de IDM que centraliza essas evidências elimina o retrabalho de manter processos separados para cada obrigação regulatória.

Como a Niuco Ajuda a Implementar os Controles de Identidade do SOC 2

A Niuco fornece controle de identidade e acessos para garantir que apenas usuários autorizados acessem dados sensíveis, com trilhas de auditoria completas e visibilidade de Shadow IT para conformidade com os princípios de segurança e privacidade do SOC 2.

Controle de acesso e visibilidade para atender ao CC6

A Niuco centraliza o mapa de acessos de todas as identidades em uma única plataforma, para colaboradores, prestadores, bots e service accounts. Para cada identidade, é possível ver em tempo real quais acessos estão ativos, quando foram concedidos, com qual aprovação e quando foram revisados pela última vez. Isso inclui visibilidade de Shadow IT, aplicativos SaaS em uso sem autorização formal, que frequentemente passam despercebidos em auditorias e se tornam achados do CC6.

O provisionamento e a revogação de acessos são automatizados com base em eventos do ciclo de vida, onboarding, mudança de função e desligamento,  o que elimina o acesso residual e garante que cada transição gere evidência auditável automaticamente.

Trilha de auditoria contínua para o CC7

A Niuco gera trilha de auditoria centralizada de todos os acessos: quem acessou o que, quando, de onde e com qual autorização. Esses registros cobrem todo o período auditado e são exportáveis no formato que o auditor SOC 2 solicita, sem necessidade de levantamento manual de logs dispersos em múltiplos sistemas. Para o CC7, a plataforma permite configurar alertas sobre comportamentos anômalos de acesso, como acessos fora de horário ou tentativas de acesso a sistemas fora do perfil do usuário.

Relatórios prontos para o período de auditoria SOC 2 Tipo 2

O maior desafio do SOC 2 Tipo 2 é demonstrar que eles funcionam continuamente por 6 a 12 meses. A Niuco gera automaticamente os relatórios de revisão periódica de acessos, registros de provisionamento, revogação e inventário de identidades ativas, tudo com timestamp, responsável e justificativa.

Faça como Ebanx, Conta Azul, Mercado Bitcoin e Gupy, e confie na Niuco. Clique aqui e solicite uma demo.

FAQ: Perguntas Frequentes sobre SOC 2 e Controle de Acesso

O que é SOC 2?

SOC 2 é um framework de atestação desenvolvido pelo AICPA que avalia os controles de uma organização de serviços em relação à segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade.  O SOC 2 resulta em um relatório de atestação emitido por auditor independente após avaliação dos controles da empresa.

O que são os Trust Service Criteria do SOC 2?

Trust Service Criteria (TSC) são os cinco critérios que estruturam o SOC 2: Segurança (obrigatório), Disponibilidade, Integridade de Processamento, Confidencialidade e Privacidade. Cada empresa define com o auditor quais critérios serão incluídos no escopo da auditoria, com base no tipo de dado que processa e nos requisitos dos seus clientes.

O que o SOC 2 exige em termos de controle de acesso?

O critério CC6 do SOC 2 exige que o acesso a sistemas e dados seja restrito a usuários autorizados, com autenticação forte, revisão periódica de permissões, processo documentado de provisionamento e revogação, controles sobre acessos privilegiados e segregação de funções em operações críticas. Para o SOC 2 Tipo 2, todas essas exigências precisam ser comprovadas com evidências cobrindo todo o período de auditoria.

Qual a diferença entre SOC 2 Tipo 1 e Tipo 2?

O SOC 2 Tipo 1 avalia se os controles estão adequadamente desenhados em um momento específico, de forma pontual. Ele geralmente é aceito apenas de forma temporária, apenas enquanto buscam pela certificação Tipo 2. Isso porque o SOC 2 Tipo 2 avalia se os controles funcionaram efetivamente ao longo de um período de 6 a 12 meses. Esse é o padrão que a maioria dos clientes corporativos americanos exige, pois demonstra que a empresa mantém conformidade continuamente.

Quanto tempo leva para obter o SOC 2?

Para o SOC 2 Tipo 1, o processo pode levar de 3 a 6 meses, incluindo a fase de preparação e a auditoria em si. Para o SOC 2 Tipo 2, é necessário um período de observação de 6 a 12 meses antes da auditoria, o que significa que o processo completo costuma levar de 9 a 18 meses. Empresas com controles já implementados e evidências organizadas tendem a completar o processo mais rapidamente.

SOC 2 e ISO 27001 se substituem?

Não. Os dois frameworks têm escopos e propósitos distintos. A ISO 27001 é uma certificação internacional reconhecida globalmente, com foco no sistema de gestão de segurança da informação. O SOC 2 é um relatório de atestação voltado principalmente para o mercado americano, com foco em controles operacionais de organizações de serviço. Muitas empresas buscam os dois e, como os controles se complementam, implementar um facilita a adequação ao outro.

Como a gestão de identidade ajuda a passar no SOC 2?

A gestão de identidade estruturada resolve a maior parte dos achados do CC6, o critério com mais ocorrências em auditorias SOC 2. Quando o ciclo de vida de identidades é automatizado, com provisionamento, revisão e revogação gerando evidências continuamente, a empresa chega à auditoria com o histórico completo já organizado. 


Leia mais 😀