Evidências de gestão de mudanças que auditores aceitam

Em uma auditoria SOC 2 Tipo II, a gestão de mudanças (CC8.1) é um dos controles mais amostrados: o auditor escolhe mudanças ao longo de todo o período e pede que você comprove que cada uma foi autorizada, testada e aprovada antes de chegar à produção. ISO 27001 (A.8.32), PCI DSS (6.5.1, 6.5.2) e o Regulamento de Execução da NIS2 (ponto 6.4) pedem a mesma coisa com outras palavras. As equipes de engenharia geralmente fazem o trabalho; o que costuma faltar é a evidência.

O que os auditores testam

Para uma amostra de mudanças, eles querem ver:

1. A mudança foi solicitada e descrita: um ticket ou pull request dizendo o que é e por quê.
2. Foi revisada por alguém diferente do autor: segregação de funções.
3. Foi testada antes da produção, com resultados.
4. Foi aprovada antes da implantação.
5. O que foi implantado é o que foi aprovado: nenhum código não revisado chegou à produção.
6. A população está completa: toda mudança em produção passou pelo processo, incluindo infraestrutura e configuração.

Evidências que atendem

• Proteção de branch: o branch principal exige pelo menos uma aprovação de revisão de alguém diferente do autor, e verificações aprovadas, antes do merge. Exporte as configurações e mostre que não mudaram durante o período.
• Implantação apenas por pipeline: as implantações em produção vêm somente do branch protegido via CI/CD; os engenheiros não conseguem fazer push direto.
• Registros vinculados: cada implantação está vinculada ao pull request mesclado, que está vinculado ao seu ticket.
• Infraestrutura como código sob as mesmas regras, para que as mudanças de infraestrutura deixem o mesmo rastro.
• Uma lista completa de mudanças da ferramenta de implantação para o período, da qual o auditor pode extrair a amostra.

Mudanças emergenciais

Todo processo precisa de um caminho rápido para incidentes, e os auditores esperam que exista um. Defina-o: quem pode aprovar, em que prazo ocorre a revisão retrospectiva (dentro de um ou dois dias úteis é comum) e como a mudança se vincula ao incidente. Depois, garanta que as mudanças emergenciais realmente sejam raras.

O que reprova auditorias

• Administradores com acesso direto à produção que às vezes contornam o pipeline.
• Pull requests autoaprovados, ou revisões feitas somente por bots.
• Mudanças de configuração feitas em um console sem registro.
• Proteção de branch desativada "temporariamente" durante o período.
• Nenhuma evidência de teste além de "CI aprovado", quando a mudança exigia mais.

Amostragem: o que o auditor fará de fato

Em um SOC 2 Tipo II, o auditor normalmente pede a população completa de mudanças em produção no período, escolhe uma amostra (o tamanho depende da população e da metodologia do auditor) e pede que você mostre, para cada mudança amostrada: a solicitação, a revisão por alguém diferente do autor, os resultados de teste, a aprovação e que o que foi implantado corresponde ao que foi aprovado.

Disso decorrem duas consequências práticas. Primeiro, a população precisa estar completa e ser exportável: se as mudanças puderem chegar à produção por mais de um caminho, cada caminho precisa de registro. Segundo, qualquer mudança amostrada sem evidência vira uma exceção no relatório. É mais barato ajustar o processo para que a evidência seja automática do que reconstruí-la durante a auditoria.

A página do SOC 2 CC8.1 mostra como o critério se mapeia para ISO 27001, PCI DSS e NIS2.

Um processo, todos os frameworks

Em nossos dados, os requisitos de gestão de mudanças se relacionam entre frameworks:

Direção	Mapeado	Vagamente relacionado	Sem mapeamento
Tem SOC 2 → precisa de NIS2	47 de 49 (96%)	1	1	relatório →
Tem NIS2 → precisa de SOC 2	37 de 61 (61%)	0	24	relatório →

Um processo baseado em pull requests, com branches protegidos e implantação apenas por pipeline, atende a SOC 2, ISO 27001, PCI DSS e NIS2 ao mesmo tempo. O PCI DSS acrescenta alguns itens extras: separar a pré-produção da produção (6.5.3), manter dados reais de contas fora dos testes (6.5.5) e confirmar os requisitos de segurança após mudanças significativas (6.5.2).

Veja o tópico Desenvolvimento Seguro para requisitos relacionados e nosso post sobre reutilização de evidências entre SOC 2, ISO 27001 e PCI DSS.

Perguntas

Pull requests contam como aprovação de mudança para SOC 2?

Geralmente sim: se o repositório exigir revisão por alguém diferente do autor antes do merge, a implantação estiver restrita ao código aprovado, e você puder demonstrar isso para uma amostra de mudanças ao longo do período.

Como as mudanças emergenciais devem ser tratadas para auditoria?

Com um processo de emergência definido: corrigir primeiro, se necessário, depois revisão retrospectiva e aprovação dentro de um prazo estabelecido, e um registro vinculando a mudança ao incidente que a justificou.