Mapear uma política para vários frameworks sem reescrevê-la
Organizações que adotam um segundo ou terceiro framework costumam reescrever suas políticas para cada um deles. Não é preciso: estruture-as uma vez e depois faça o mapeamento.
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.
Um padrão comum: a empresa redige um conjunto de políticas para a ISO 27001; depois, um cliente pede SOC 2, alguém compra um segundo pacote de modelos e, então, o PCI DSS chega com seus próprios requisitos. Resultado: três conjuntos de políticas sobrepostos, cada um um pouco desatualizado e nenhum refletindo o que as pessoas realmente fazem. As políticas não precisam ser específicas de um framework. Precisam ser específicas da organização e mapeadas.
Estrutura: três camadas
- Uma política de segurança da informação: curta, aprovada pela liderança, que declare objetivos, escopo, responsabilidades e comprometimento. A cláusula 5.2 da ISO 27001 e o item 12.1.1 do PCI DSS exigem essa política.
- Políticas por tópico (uma dúzia, aproximadamente): controle de acesso, uso aceitável, gestão de ativos, criptografia, resposta a incidentes, continuidade de negócios, segurança de fornecedores, desenvolvimento seguro, gestão de vulnerabilidades e patches, registro e monitoramento, segurança física e segurança de RH.
- Procedimentos e padrões abaixo delas, onde ficam as frequências, configurações e etapas. Esses itens mudam com mais frequência e não deveriam exigir aprovação da liderança a cada alteração.
Coloque os detalhes específicos de cada framework nos procedimentos, não nas políticas: “o acesso é revisado a cada seis meses” pertence ao procedimento de revisão de acesso, onde a frequência exigida pelo PCI DSS pode constar sem inflar a política.
Mapear, não reescrever
Mantenha uma tabela de mapeamento: uma linha por seção da política, com os requisitos que ela atende em cada framework. O tópico Governance Policy mostra o que cada framework espera no nível mais alto:
| Framework | Política de governança | Vínculo |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01GV.PO-02 | Definição do tópico |
| ISO 27001 | A.5.1A.5.37Clause 5.2 | Correspondência |
| CIS v8.1 | — | Sem mapeamento em nossos dados |
| SOC 2 | CC5.3CC1.1 | Editorial |
| PCI DSS | 12.1.112.1.2 | Correspondência |
| CMMC | — | Sem mapeamento em nossos dados |
| 800-53 | PM-1PL-1 | Correspondência |
| HIPAA | §164.316(a)§164.316(b)(2)(iii) | Correspondência |
| GDPR | Art.24(2) | Editorial |
| NIS2 | 1.1 | Correspondência |
| Essential Eight | — | Sem mapeamento em nossos dados |
Detalhe completo e o motivo de cada ligação: Política de governança em todos os frameworks →
Quando chegar um novo framework, faça uma análise de lacunas e examine os requisitos de governança e de políticas: a maioria será mapeada para uma política que você já possui; os demais se tornam novas seções ou procedimentos.
O que os frameworks exigem especificamente por escrito
- ISO 27001: uma política de segurança da informação (5.2) e políticas específicas por tópico conforme necessário (A.5.1), comunicadas e revisadas.
- SOC 2: políticas que estabeleçam o que é esperado, implementadas por meio de procedimentos (CC5.3).
- PCI DSS: para cada um de seus doze requisitos, políticas e procedimentos documentados e atualizados (x.1.1) e papéis atribuídos (x.1.2), revisados pelo menos anualmente.
- NIS2: uma política sobre a segurança de redes e sistemas de informação e políticas específicas por tópico (Regulamento de Execução, ponto 1).
- NIST CSF 2.0: a política é estabelecida, comunicada e aplicada (GV.PO).
Um conjunto mínimo de políticas
Para a maioria das organizações de pequeno e médio porte, estes documentos cobrem os requisitos de política da ISO 27001, do SOC 2, do NIST CSF, do PCI DSS e da NIS2:
- Política de segurança da informação (nível superior, aprovada pela liderança)
- Política de uso aceitável
- Política de controle de acesso
- Política de gestão de ativos e classificação de dados
- Política de criptografia
- Política de desenvolvimento seguro e gestão de mudanças
- Política de gestão de vulnerabilidades e patches
- Política de registro e monitoramento
- Política de resposta a incidentes (com obrigações de notificação)
- Política de continuidade de negócios e backup
- Política de segurança de fornecedores
- Política de segurança de recursos humanos
- Política de segurança física
São treze documentos, a maioria com poucas páginas, cada um com um responsável e uma data de revisão. Os procedimentos trazem os detalhes e mudam com mais frequência.
Principais conclusões
- As políticas devem ser específicas da organização e mapeadas, não específicas de um framework.
- Coloque frequências e configurações em procedimentos.
- Treze políticas curtas cobrem a maioria dos frameworks.
- O PCI DSS exige que suas políticas e procedimentos sejam revisados pelo menos anualmente.
Mantenha-as atualizadas
- Escreva o que você faz, não o que diz um modelo. Auditores testam as políticas contra a prática.
- Revise anualmente e após mudanças significativas, com aprovação registrada.
- Curto vale mais que completo: uma política de controle de acesso de duas páginas que as pessoas leem é melhor do que vinte páginas que ninguém lê.
Para um conjunto comum de controles completo, baseado na mesma ideia, veja um conjunto de controles para SOC 2 e ISO 27001.
Perguntas
Quantas políticas de segurança você precisa?
Menos do que a maioria dos modelos sugere. Uma política de segurança da informação de nível superior, somada a uma dúzia de políticas por tópico (acesso, uso aceitável, resposta a incidentes, segurança de fornecedores e assim por diante), normalmente cobre a ISO 27001, o SOC 2, o NIST e o PCI DSS.
O PCI DSS exige políticas específicas?
Sim. Cada requisito do PCI DSS começa com a exigência de políticas e procedimentos documentados e atualizados para aquela área (x.1.1), além de papéis e responsabilidades (x.1.2).
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-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.
Análise · 2026-10-13Requisitos de MFA comparados em 11 frameworks de segurançaQuais frameworks exigem MFA, para quem e com que rigor: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 e HIPAA, comparados lado a lado.