Neste artigo:
- O que é a ISO 27001 e como ela se relaciona ao SOC
- A estrutura que suporta o SOC na norma
- Controles do Anexo A diretamente relacionados ao SOC
- O ciclo PDCA e a operação do SOC
- SOC terceirizado e ISO 27001
- Declaração de Aplicabilidade e o papel do SOC
- O que avaliar em um parceiro de SOC
- Conclusão
O que é a ISO 27001 e como ela se relaciona ao SOC
A edição de 2022 da norma trouxe mudanças significativas: reorganizou os controles do Anexo A e adicionou novos, especialmente relevantes para operações de segurança. Para quem opera ou contrata um SOC, entender essa estrutura é fundamental — não só para passar na auditoria, mas para construir uma operação que realmente reduza risco.
Diferente do PCI DSS, que é prescritivo e setorial, a ISO 27001 é baseada em risco e se aplica a qualquer tipo de organização. Essa flexibilidade é uma força — e uma armadilha. A norma não diz exatamente o que fazer; ela exige que a organização determine o que é necessário com base em seus riscos, implemente, monitore e prove que funciona.
Para o CISO e o time de compliance, isso implica um ponto de atenção direto: o SOC não é um componente opcional da certificação. Ele é a espinha dorsal operacional do Sistema de Gestão de Segurança da Informação (SGSI).
A estrutura que suporta o SOC na norma
A norma é organizada em duas partes que interagem diretamente com o SOC: o corpo principal (cláusulas 4 a 10, que definem o SGSI) e o Anexo A (93 controles em quatro temas). Um SOC efetivo é, em grande medida, a operacionalização de múltiplos controles desse Anexo.
Cláusulas principais com impacto direto no SOC
| Cláusula | Nome | Impacto para o SOC |
|---|---|---|
| 6.1 | Avaliação e tratamento de riscos | Casos de uso de detecção devem ser rastreáveis ao registro de riscos |
| 8.2 | Avaliação de riscos de segurança | O SOC é fonte primária de dados para avaliações periódicas |
| 9.1 | Monitoramento, medição e avaliação | KPIs do SOC (MTTD, MTTA, falso positivo) são evidências diretas desta cláusula |
| 10.2 | Melhoria contínua | Revisões de incidentes e atualização de playbooks operacionalizam essa exigência |
Controles do Anexo A diretamente relacionados ao SOC
A revisão de 2022 reorganizou os controles em quatro categorias: organizacionais, pessoais, físicos e tecnológicos. Para uma operação de SOC, os controles tecnológicos e organizacionais são os mais críticos.
Controles tecnológicos críticos
| Controle | Nome | O que exige do SOC |
|---|---|---|
| A.8.15 (novo) | Log de eventos | Logs produzidos, armazenados, protegidos e analisados sistematicamente |
| A.8.16 (novo) | Atividades de monitoramento | Redes, sistemas e aplicações monitorados para detectar comportamentos anômalos |
| A.8.7 | Proteção contra malware | SOC responsável pela detecção e resposta em toda a organização |
| A.8.8 | Gestão de vulnerabilidades técnicas | Integração SOC ↔ vulnerability management para triagem e priorização |
| A.8.23 (novo) | Filtragem web | Proxies e DNS security integrados aos feeds do SOC |
| A.8.28 (novo) | Codificação segura | Telemetria de aplicações incorporada ao monitoramento, além de infraestrutura |
Controles organizacionais essenciais
| Controle | Nome | O que exige do SOC | Evidência esperada |
|---|---|---|---|
| A.5.24 | Planejamento de resposta a incidentes | Processo formal com papéis definidos | Plano documentado, testado, com registro de ativações |
| A.5.25 | Avaliação de eventos de segurança | Processo para decidir se um evento se torna incidente | Critérios de escalada documentados e histórico de triagem |
| A.5.26 | Resposta a incidentes | Resposta conforme procedimentos documentados | Playbooks por categoria, registros de resposta |
| A.5.27 | Aprendizado com incidentes | Lições aprendidas usadas para fortalecer controles | Relatórios pós-incidente, atualizações rastreáveis de playbook |
| A.5.28 | Coleta de evidências | Procedimentos para identificar, coletar e preservar evidências | Cadeia de custódia documentada, metodologia forense |
| A.5.7 (novo) | Inteligência de ameaças | Informações sobre ameaças coletadas e analisadas sistematicamente | Feeds de CTI ativos, processo de atualização das regras de detecção |
Destaque — A.5.7 Inteligência de Ameaças
O controle A.5.7 é novo na versão de 2022 e representa uma mudança de postura: a ISO 27001 passou a exigir que a organização não seja apenas reativa, mas que colete e use inteligência sobre ameaças de forma sistemática. Para o SOC, isso significa que threat hunting e atualização de casos de uso de detecção com base em CTI deixaram de ser diferenciais — passaram a ser requisitos auditáveis.
O ciclo PDCA e a operação do SOC
A ISO 27001 é estruturada em torno do ciclo Plan-Do-Check-Act (PDCA). Um SOC que opera dentro de um SGSI certificado precisa demonstrar que contribui para cada fase desse ciclo — não apenas para a fase de execução.
Plan — Planejamento baseado em risco
Do — Operação e monitoramento contínuo
Check — Medição e avaliação de eficácia
Act — Melhoria contínua documentada
SOC terceirizado e ISO 27001
A ISO 27001 permite explicitamente que controles sejam implementados por terceiros — mas a responsabilidade pela eficácia permanece com a organização certificada. Os controles A.5.19 (Segurança da informação em relacionamentos com fornecedores) e A.5.22 (Monitoramento, revisão e gestão de mudanças de serviços de fornecedores) são auditados com rigor quando o SOC é terceirizado.
⚠️ Ponto de atenção — Auditorias de terceiros
O auditor da certificação vai verificar se a organização consegue demonstrar evidências dos controles — mesmo que quem os opere seja um provedor externo. O contrato com o SOC terceirizado precisa garantir acesso a métricas, logs e relatórios suficientes para que a organização sustente sua própria auditoria. Um SOC que só entrega relatório mensal em PDF não atende a esse requisito.
Perguntas que um auditor ISO 27001 fará sobre o SOC terceirizado
- Como a organização verifica que o serviço está sendo prestado conforme acordado? — Evidência: revisões periódicas de SLAs e relatórios de KPIs com série histórica
- Como incidentes detectados pelo SOC alimentam o processo de gestão de incidentes? — Evidência: integração documentada entre o processo de resposta do provedor e o processo interno
- Como a organização garante que aprendizados de incidentes são incorporados? — Evidência: registro de lições aprendidas com rastreabilidade para atualizações de controles
- Como o SOC contribui para a avaliação de riscos? — Evidência: dados de telemetria e incidentes usados na revisão periódica do registro de riscos
- O que acontece se o serviço do SOC for interrompido? — Evidência: plano de continuidade que cobre a indisponibilidade do serviço de monitoramento
Para aprofundar o tema de gestão de fornecedores em segurança, veja também como estruturar o processo de due diligence de terceiros em ambientes regulados.
Declaração de Aplicabilidade e o papel do SOC
A Declaração de Aplicabilidade (SoA) é um documento central da ISO 27001: lista todos os controles do Anexo A, indica quais são aplicáveis, justifica a exclusão dos demais e, para os aplicáveis, evidencia como estão implementados. Um SOC efetivo torna vários controles "aplicáveis e implementados" na SoA — e é a prova dessa implementação que o auditor vai buscar.
| Controle | Evidência típica do SOC | Frequência de revisão |
|---|---|---|
| A.8.15 | Arquitetura de logging, política de retenção, amostras de logs | Anual + evento |
| A.8.16 | Dashboard de monitoramento, casos de uso ativos no SIEM, relatórios periódicos | Mensal + evento |
| A.5.24 | Plano de resposta a incidentes, resultado do último exercício de tabletop | Anual |
| A.5.26 | Playbooks por categoria, registros de resposta a incidentes anteriores | Trimestral |
| A.5.7 | Fontes de CTI ativas, processo de atualização de regras de detecção | Mensal |
| A.5.28 | Procedimento de coleta de evidências, exemplos de cadeia de custódia | Anual + incidente |
O que avaliar em um parceiro de SOC
Se o modelo escolhido for SOC terceirizado, os critérios de avaliação precisam ir além do que o fornecedor entrega internamente. A organização precisa ser capaz de usar o serviço como evidência em sua própria auditoria ISO 27001.
- O provedor entrega métricas rastreáveis por período? (MTTD, MTTA, volume de alertas, incidentes por categoria)
- É possível acessar logs brutos ou apenas relatórios tratados?
- O provedor participa de exercícios de tabletop e revisões de plano?
- Como incidentes são documentados e transferidos para o registro interno?
- O provedor possui sua própria certificação ISO 27001?
- Como o serviço evoluiu nos últimos 12 meses?
Para entender como estruturar a contratação de um SOC como serviço, consulte nosso guia sobre SOC gerenciado: critérios técnicos e contratuais para CISOs e também como montar um programa de gestão de incidentes alinhado à ISO 27001.
Além disso, a norma completa está disponível para consulta diretamente no site da ISO.
Conclusão
A ISO 27001 não certifica ferramentas — ela certifica que a organização tem um sistema de gestão que funciona. O SOC é a espinha dorsal operacional desse sistema: é ele quem produz as evidências de monitoramento contínuo, resposta a incidentes e melhoria progressiva que sustentam a certificação ao longo do tempo.
Para diretores de TI, CISOs e equipes de compliance, o recado prático é direto: um SOC que não produz evidências auditáveis, não alimenta a avaliação de riscos e não demonstra evolução não sustenta uma certificação de verdade. Sustenta apenas o papel que a representa.
Investir em uma operação de SOC alinhada à ISO 27001 é, acima de tudo, uma decisão de gestão de risco — e uma que tem retorno mensurável em resiliência operacional e redução de exposição regulatória.
Leia também:
- SOC Gerenciado: critérios técnicos e contratuais para CISOs
- Programa de gestão de incidentes alinhado à ISO 27001
- Due diligence de terceiros em ambientes regulados