Com a crescente onda de cyberataques e roubo de informações houve um aumento da demanda pela implantação e melhoria contínua do processo de Gestão de Riscos e Compliance, tanto nas empresas quanto pelos órgãos reguladores.
O BACEN (Banco Central do Brasil), por exemplo, exige que os bancos tenham uma política de segurança cibernética e avaliem seus fornecedores de serviços críticos periodicamente, havendo ainda a obrigatoriedade de informar os resultados de tais avaliações ao regulador. Isso se estende a SUSEP (Superintendência de Seguros Privados) e a outros órgãos reguladores.
Um efeito importante desse nível de exigência em relação a gestão de riscos e implementação de processos e controles de segurança da informação é que o tema acaba se estendendo a toda a cadeia de valor das empresas, envolvendo inclusive prestadores de serviço. A Lei Geral de Proteção de Dados Pessoais, Lei nº 13.709/2018, institui que uma empresa que tenha seus dados vazados, mesmo que seja a partir de um prestador de serviços, responderá solidariamente pelo incidente.
Todos esses aspectos supracitados, além de risco reputacional e financeiro, têm gerado uma demanda, não só por implementação de controles internos, mas como pela comprovação da efetividade destes.
Uma das formas de se comprovar que existe uma estrutura de controles internos implementada e com riscos controlados é através de certificações providas por entidades independentes. Pode-se destacar como algumas das principais certificações com esse intuito a SOC (Service Organization Control) 1, 2 ou 3.
Historicamente, as raízes do SOC 2 remontam ao início dos anos 1970 quando o AICPA (American Institute of Certified Public Accountants), que criou o SOC 2, divulgou o Statement on Auditing Standards (SAS) 1.
O documento SAS 1 delineou oficialmente o papel e as responsabilidades de um auditor independente.
Décadas se passaram e novos SAS foram criados, até o SAS 70 em 1992.
Ao longo do início da década de 1990, os CPAs usaram o SAS 70 para determinar a eficácia dos controles financeiros internos de uma empresa. Com o tempo, o SAS 70 tornou-se uma forma de relatar como as empresas tratavam a segurança da informação em geral.
Nos 20 anos seguintes, as empresas começaram a terceirizar serviços como processamento de folha de pagamento e computação em nuvem. E esses serviços podem afetar os relatórios financeiros ou a segurança dos dados.
Como resultado, surgiu a necessidade de as empresas validarem seu nível de segurança, idealmente por meio de um terceiro confiável.
Quando o SOC 2 começou?
Em abril de 2010, o AICPA anunciou um novo padrão de auditoria: o Statement on Standards for Attestation Engagement (SSAE 16).
Sob o SSAE 16, o AICPA divulgou três novos relatórios. Isso resultou no Service Organization Controls (SOC) e no popular SOC 2, embora existam também o SOC 1 e SOC 3.
Em maio de 2017, o AICPA substituiu o SSAE 16 pelo SSAE 18 para atualizar e simplificar alguns aspectos confusos do SSAE 16.
O SSAE 18 agora é usado para todos os relatórios SOC 1, SOC 2 e SOC 3. Mas qual é a diferença entre eles?
SOC 1
O intuito do SOC 1 é avaliar a estrutura de controles da empresa focados em auditoria financeira, ou seja, que impliquem de alguma forma no balanço financeiro dos clientes para quem os serviços são prestados. Esse relatório é pedido normalmente para empresas que oferecem serviços como folha de pagamento, processamento de pagamentos, controle de ponto de funcionários, etc.
SOC 2
O intuito do SOC 2 é avaliar a estrutura de controles internos da empresa de uma forma mais abrangente, focada na segurança da informação como um todo. Cinco aspectos, chamados de Trust Services Criteria podem ser avaliados, a saber:
- Segurança: Proteção das informações contra acesso não autorizado;
- Disponibilidade: Garantia de que funcionários e clientes possam confiar em seus sistemas para fazer seu trabalho;
- Integridade do processamento: Verificação dos sistemas da empresa se funcionam como pretendido;
- Confidencialidade: Proteção de informações confidenciais limitando seu acesso, armazenamento e uso;
- Privacidade: Proteção a informações pessoais confidenciais contra usuários não autorizados.
Apenas o primeiro critério (Segurança) é obrigatório no processo de certificação, ficando os demais a escolha da empresa auditada.
SOC 3
O intuito do SOC 3 é oferecer um resumo do relatório SOC 2. Tanto o relatório SOC 1 quanto o SOC 2 possuem informações detalhadas sobre a infraestrutura tecnológica e de controles da empresa auditada, além da visão do auditor em relação aos mesmos. Dessa forma ambos são confidenciais e devem ter seu acesso muito bem controlado. Já o relatório SOC 3 oferece um resumo do relatório SOC 2, com apenas informações públicas, descrevendo os testes realizados e a visão do auditor. Esse relatório pode ser disponibilizado a qualquer pessoa ou empresa.
É importante que fique claro que os relatórios não representam uma crescente de maturidade e não é necessário ter o SOC 1 para ter o SOC 2. Apenas é necessário ter o relatório SOC 2 para se obter o SOC 3, uma vez que esse é um resumo do outro.
Qual relatório SOC escolher?
Decidir qual relatório SOC faz mais sentido para uma empresa vai depender exclusivamente do tipo de informação que ela está processando para seus clientes.
Por exemplo, se a empresa estiver fornecendo serviços de processamento de folha de pagamento, provavelmente precisará de um SOC 1. Se estiver hospedando ou processando dados de clientes, precisará de um relatório SOC 2. Os relatórios SOC 3 são menos formais e são mais bem usados como material de marketing.
Finalmente, algumas organizações precisam de um relatório SOC 1 e SOC 2. Isso dependerá dos serviços que ela fornece e de seus clientes. Ela pode ter clientes solicitando um SOC 1 e outros clientes solicitando um SOC 2, mas haverá sobreposição em ambos, o que pode agilizar a realização dos testes.
