Checklist de change management para TI: do pedido de deploy à verificação pós-deploy

Um deploy sai na sexta à tarde. Sem registro de aprovação. Sem plano de rollback. Na segunda, o sistema está fora do ar e a revisão pós-incidente revela que a mudança passou por fora do processo de aprovação porque 'era urgente.' O finding de auditoria se escreve sozinho.

Change management é o controle mais frequentemente citado em auditorias SOC 2 e ISO 27001, e o mais frequentemente executado informalmente. Uma mensagem no Slack dizendo 'deployando agora' não é uma aprovação. Um ticket do Jira marcado como feito não é um registro de verificação.

Um checklist de deploy estrutura o processo em quatro fases: solicitação com escopo e avaliação de risco, aprovação pelo papel adequado baseado na categoria da mudança, execução com plano de rollback documentado e verificação pós-deploy confirmando que a mudança se comporta como esperado.

A distinção crítica é entre mudanças de rotina e emergência. Mudanças de rotina seguem o checklist completo. Mudanças de emergência seguem um caminho abreviado, mas ainda exigem um aprovador nomeado, um plano de rollback e verificação pós-deploy dentro de 24 horas. O caminho de emergência não pula controles; ele comprime o prazo.

O valor para auditoria está no registro imutável. Cada deploy tem uma solicitação, uma aprovação com nome do aprovador e timestamp, um plano de rollback e uma verificação. Quando um auditor pergunta como mudanças são gerenciadas, a resposta não é um documento de política, é um histórico de execução mostrando cada mudança no último ciclo com evidência anexada.