O núcleo comum: requisitos de segurança que todo framework compartilha
Ao mapear onze frameworks de segurança entre si, surge um pequeno núcleo presente em todos eles. Se você está começando um programa ou lidando com vários frameworks, é por esse núcleo que convém começar.
Esta publicação abrange as 11 normas que a ControlMapping tinha mapeado quando foi escrita. Desde então, foram acrescentadas DORA, CPS 234, Cyber Essentials em 2026-10-27; as respetivas páginas e a matriz de cobertura já as incluem.
As organizações raramente respondem a um único framework de segurança. Uma empresa de software vende para clientes nos EUA que exigem um relatório SOC 2 e para clientes europeus que exigem ISO 27001; um provedor de pagamentos acrescenta o PCI DSS; um provedor digital da UE passa a estar sujeito ao NIS2. Cada framework chega com estrutura, numeração e vocabulário próprios, e é fácil concluir que cada um exige um programa separado.
Não exige. Sob a numeração diferente existe muita base comum, e uma parte pequena dela é compartilhada por todos os frameworks que mapeamos. Procuramos os tópicos que têm um requisito mapeado nos onze: NIST CSF 2.0, NIST SP 800-53, ISO 27001, CIS Controls, SOC 2, PCI DSS, CMMC Level 2, a Security Rule da HIPAA, GDPR, NIS2 e o Essential Eight da ASD.
Os cinco tópicos presentes em todos os frameworks
5 de 50 temas têm um requisito mapeado em todos os 11 frameworks. Cada página de tema lista os IDs de requisito de cada framework e as evidências de cada vínculo.
Esse é o núcleo comum: gestão de ativos, gestão de vulnerabilidades, backup e recuperação, resposta a incidentes e notificação de incidentes. Cada um dos onze frameworks tem pelo menos um requisito em cada um desses tópicos, inclusive o GDPR, que é uma lei de privacidade, e o Essential Eight, que é uma lista curta de mitigações técnicas.
A lista é curta de propósito. Muitos outros tópicos, como controle de acesso, registro de logs e criptografia, são cobertos por dez dos onze, e a maioria dos frameworks compartilha bem mais de cinco tópicos. Mas esses cinco são os que nenhum framework deixa de fora.
Por que esses cinco
Eles acompanham o ciclo de vida de um incidente. Não é possível proteger aquilo que não se sabe que existe (gestão de ativos). A maioria dos ataques ainda explora fraquezas conhecidas (gestão de vulnerabilidades). Quando algo dá errado, é preciso restaurar sistemas e dados (backup e recuperação), conduzir o incidente (resposta a incidentes) e informar quem precisa saber: a direção, os clientes e os reguladores (notificação de incidentes).
Os frameworks divergem em quase tudo o mais: se a governança é um sistema de gestão ou um conjunto de resultados, o quão prescritivos devem ser os controles técnicos, com que frequência as ações devem ocorrer. Nesses cinco há consenso, porque sem eles o restante não funciona.
Mesmo tópico, profundidade diferente
Um tópico compartilhado não significa um requisito idêntico. Veja a gestão de vulnerabilidades:
| Framework | Gestão de Vulnerabilidades | Vínculo |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01ID.RA-08 | Definição do tópico |
| ISO 27001 | A.8.8 | Correspondência |
| CIS v8.1 | CIS 7.1CIS 7.2CIS 7.5CIS 7.6CIS 7.7CIS 16.6CIS 18.1CIS 18.2CIS 18.3CIS 18.4CIS 18.5 | Correspondência |
| SOC 2 | CC7.1 | Editorial |
| PCI DSS | 6.3.111.3.111.3.2 | Correspondência |
| CMMC | RA.L2-3.11.2RA.L2-3.11.3 | Correspondência |
| 800-53 | RA-5CA-8 | Correspondência |
| HIPAA | §164.308(a)(1)(ii)(A)§164.308(a)(1)(ii)(B)§164.308(a)(8) | Correspondência |
| GDPR | Art.32(1)(d) | Editorial |
| NIS2 | 6.56.10 | Correspondência |
| Essential Eight | ISM-1807ISM-1808ISM-1698ISM-1699ISM-1701ISM-1702 | Editorial |
Detalhe completo e o motivo de cada ligação: Gestão de Vulnerabilidades em todos os frameworks →
O A.8.8 da ISO 27001 pede que você obtenha informações sobre vulnerabilidades técnicas, avalie sua exposição e tome as medidas apropriadas, deixando o prazo a cargo da sua avaliação de riscos. O PCI DSS exige varreduras internas a cada três meses e após mudanças significativas (11.3.1), varreduras externas feitas por um Approved Scanning Vendor (11.3.2), e a aplicação de patches de criticidade crítica e alta em até um mês após a liberação (6.3.3). O Essential Eight define prazos de patching que se tornam mais rigorosos a cada nível de maturidade. A HIPAA aborda o tópico por meio de seus requisitos de análise de riscos e gestão de riscos, e não por um requisito específico sobre vulnerabilidades.
Assim, o núcleo comum informa o que todo framework espera que você faça, não o quanto. Ao construir um controle, projete-o para o framework mais rigoroso que você atende, e os demais normalmente serão atendidos em seguida.
Como isso se apresenta na prática
- Gestão de ativos: um inventário único de hardware, software, serviços em nuvem e repositórios de dados, com responsáveis definidos, mantido atualizado por ferramentas de descoberta e não apenas por planilhas.
- Gestão de vulnerabilidades: varreduras programadas (internas e externas), classificação de severidade, prazos de correção por severidade e evidências de que os prazos são cumpridos.
- Backup e recuperação: backups de dados, software e configurações, protegidos contra alteração e exclusão, com restaurações testadas conforme um cronograma.
- Resposta a incidentes: um plano escrito com papéis, níveis de severidade e escalonamento, testado pelo menos uma vez por ano.
- Notificação de incidentes: um procedimento que define quem deve ser informado, em que prazo e por quem: a direção interna, os clientes sob contrato e os reguladores (por exemplo, o alerta antecipado de 24 horas do NIS2 ou a notificação em 72 horas à autoridade de controle prevista no GDPR).
Por que o núcleo importa
Se você está começando um programa de segurança, implemente primeiro esses cinco. São os requisitos que você encontrará em todo framework que possa adotar no futuro, portanto o trabalho nunca é desperdiçado.
Se você já lida com vários frameworks, use o núcleo como base de um conjunto comum de controles: um controle para cada um desses tópicos, mapeado para cada framework que você atende, com evidências coletadas uma única vez. A mesma ideia se estende aos tópicos compartilhados por dez, nove ou oito frameworks. Nossa matriz de cobertura mostra todos os cinquenta tópicos em relação aos onze frameworks, e a análise de lacunas mostra, requisito por requisito, o que se aproveita entre quaisquer dois deles.
Como medimos
Cada tópico no ControlMapping é definido pelos resultados do NIST CSF 2.0 e lista o requisito de cada framework que o aborda. Um vínculo é rotulado como Correspondência quando uma correspondência publicada (do NIST, da ENISA, da CIS ou da PCI SSC) o sustenta, e como Editorial quando reflete nosso julgamento, com o motivo exibido. Os vínculos do SOC 2, do GDPR e do Essential Eight são sempre Editoriais, porque não existe correspondência com licença aberta para eles. O método completo está na página de metodologia, e todos os números acima vêm dos dados em tempo real, de modo que são atualizados quando os mapeamentos mudam.
Perguntas
Quais controles de segurança são exigidos por todos os frameworks?
Nos dados do ControlMapping, cinco tópicos têm um requisito mapeado nos 11 frameworks: gestão de ativos, gestão de vulnerabilidades, backup e recuperação, resposta a incidentes e notificação de incidentes. A redação exata e a profundidade variam de framework para framework.
Atender à versão de um framework satisfaz os demais?
Não automaticamente. Um mapeamento significa que os requisitos abordam o mesmo tópico; um deles pode ser muito mais específico (o PCI DSS e o Essential Eight definem prazos e frequências que a ISO 27001 deixa a seu critério). Verifique o texto de cada framework.
Dados atualizados em 2026-10-27: os números deste artigo são calculados a partir da correspondência atual e são atualizados quando ela muda. Correspondência um crosswalk publicado (NIST, ENISA, CIS, PCI SSC) estabelece a correspondência · Editorial Juízo editorial da ControlMapping onde não existe crosswalk; o motivo é indicado · compartilha apenas um resultado do CSF 2.0: vale verificar, mas não é um mapeamento · Sem mapeamento em nossos dados nada mapeado em nossos dados; muitas vezes é trabalho novo, mas verifique as notas de cobertura. Não é aconselhamento de conformidade.
Publicações relacionadas
Análise · 2026-10-27APRA CPS 234 e ISO 27001: o que seu ISMS cobre e o que a APRA acrescentaUm ISMS ISO 27001 cobre quase todos os parágrafos da CPS 234 da APRA, mas a APRA acrescenta deveres do Conselho, garantia de terceiros e prazos rigorosos de notificação.
Análise · 2026-10-27Cyber Essentials vs Essential Eight: duas bases nacionaisO Cyber Essentials do Reino Unido e o Essential Eight da Austrália visam ataques comuns, mas cobrem terrenos diferentes. O que se sobrepõe, o que não se sobrepõe e por quê.
Análise · 2026-10-27DORA vs NIS2: o que um programa NIS2 já cobreDORA e NIS2 compartilham a maior parte do seu conteúdo de segurança, mas o DORA acrescenta um registro, cláusulas contratuais e testes orientados por ameaças. Artigo por artigo, veja o que se aproveita.