Checklist de offboarding de clientes MSP: acessos, agentes e dados

Um cliente vai embora.

Você encerra a cobrança.

Mas um agente continua instalado, uma sessão ainda funciona e ninguém sabe quais dados devem ser mantidos.

É aí que o risco começa.

Offboarding não é um botão. É um encerramento controlado que protege o cliente, o MSP e as evidências do que aconteceu.

> Baixe o modelo XLSX de offboarding para MSPs. Ele inclui 26 controles, progresso automático e abas em espanhol, inglês e português.

1) Defina quem autoriza o encerramento e quando ele acontece

Não comece desinstalando agentes.

Primeiro, documente:

• quem solicitou o encerramento;
• quem pode aprovar as ações;
• data, hora e fuso horário do corte;
• serviços, locais, usuários e endpoints dentro do escopo;
• período de transição, se houver;
• obrigações contratuais ainda pendentes;
• quem receberá documentação, segredos e relatórios;
• quais ações exigem aprovação adicional.

Isso evita o pior cenário: remover acesso cedo demais, interromper a operação ou entregar informações a um contato que já não está autorizado.

O SLA do MSP também deve explicar o que acontece durante o encerramento: quais canais continuam ativos, quando a cobertura termina e como incidentes abertos serão tratados.

2) Congele o inventário antes de mudar qualquer coisa

Você precisa de uma fotografia final do ambiente.

Antes de revogar ou excluir, registre:

• endpoints gerenciados e o último contato;
• usuários e contas com acesso;
• agentes, ferramentas remotas e utilitários instalados;
• licenças, assinaturas e renovações;
• integrações, webhooks, chaves API e aplicativos empresariais;
• backups e todos os locais onde existem cópias;
• tickets, projetos, incidentes e mudanças em aberto;
• dispositivos offline, desaparecidos ou inacessíveis.

Use o mesmo escopo do início do serviço. Se o checklist de onboarding de endpoints registrava 42 dispositivos e a sua console agora mostra 39, não presuma que os outros três desapareceram. Investigue e registre a exceção.

3) Prepare um pacote de entrega que o cliente consiga usar

Não entregue uma pasta cheia de arquivos sem contexto.

De acordo com o escopo, o pacote de saída deve incluir:

• inventário final de hardware e software;
• estado de patches, alertas e riscos conhecidos;
• tickets abertos e próximas ações;
• diagramas de rede e dependências relevantes;
• runbooks e procedimentos vigentes;
• contatos de fornecedores;
• licenças e ativos pertencentes ao cliente;
• localização, validade e responsabilidade pelos backups;
• decisões que o próximo fornecedor ou a equipe interna ainda precisa tomar.

Marque quais documentos são finais, quais servem apenas como referência e quais informações perdem validade depois do corte. Ao transferir segredos, use um canal criptografado separado e confirme que o destinatário conseguiu abri-los.

Os relatórios RMM para clientes podem fornecer as evidências iniciais, mas o pacote de entrega também precisa de contexto: pendências, exceções e decisões.

4) Revogue acessos, sessões e credenciais

Desativar uma conta nem sempre encerra todas as sessões existentes.

A Microsoft explica que alguns aplicativos mantêm seus próprios cookies ou tokens de sessão. Além de bloquear novos logins, pode ser necessário revogar sessões e desprovisionar o acesso dentro de cada aplicativo.

Como referência de controle, a NIST SP 800-171 Rev. 3 inclui ações de encerramento como desabilitar acesso e revogar autenticadores e credenciais. Isso não torna a publicação obrigatória para todo MSP; mostra por que as ações de encerramento devem ser oportunas e verificáveis.

Revise pelo menos:

1. contas de técnicos, administradores e subcontratados;
2. usuários do cliente no RMM, PSA, documentação e portais do MSP;
3. sessões ativas e refresh tokens;
4. acesso remoto, VPN e ferramentas de suporte;
5. Microsoft 365, nuvem, SaaS e portais de fornecedores;
6. senhas compartilhadas;
7. chaves API, segredos, chaves SSH e códigos de recuperação;
8. integrações, aplicativos empresariais e webhooks;
9. dispositivos registrados ou confiáveis;
10. contas de emergência e acessos temporários.

Se o MSP conhecia uma credencial, o encerramento deve dizer quem fará a rotação, quando e como o resultado será verificado. Nosso guia sobre sessões ativas em um RMM explica por que fechar o navegador não equivale a revogar o acesso.

5) Remova ou transfira agentes sem perder rastreabilidade

Um agente não deve permanecer instalado por hábito.

Também não deve ser removido antes de confirmar o destino do endpoint e a autorização necessária.

Classifique cada dispositivo:

Depois, revise tarefas agendadas, scripts, políticas, implantações automáticas, túneis, contas locais e utilitários criados pelo MSP. O agente visível costuma ser apenas uma parte do acesso operacional.

No Lunixar RMM, o inventário e o último estado reportado ajudam a conciliar endpoints. A autorização, a transferência e a verificação final continuam sendo responsabilidades do processo de offboarding.

6) Decida quais dados serão devolvidos, mantidos e excluídos

“Excluir tudo” pode ser tão errado quanto “guardar tudo para sempre”.

Separe as informações em três grupos:

1. Devolver: inventários, relatórios, documentação, configurações e ativos do cliente.
2. Manter: faturamento, aprovações, evidências contratuais ou registros que precisem permanecer por um período definido.
3. Excluir: cópias operacionais, exportações temporárias, segredos e dados que já não tenham uma finalidade válida.

Dentro do seu escopo de identidade digital, a NIST SP 800-63A diz que informações pessoais associadas a contas encerradas devem ser removidas conforme uma política documentada de retenção e descarte. A ideia útil para um MSP é simples: defina o período e o motivo antes de manter informações.

Quando mídias ou cópias precisarem de sanitização, a NIST publicou em 2025 a SP 800-88 Rev. 2, que organiza as decisões conforme a sensibilidade da informação, o tipo de mídia e o esforço necessário para impedir a recuperação.

Não transforme essas referências em aconselhamento jurídico automático. O contrato, o tipo de dado, a jurisdição e as obrigações fiscais ou regulatórias determinam o que realmente deve ser feito.

7) Encerre licenças, renovações e faturamento

Custos esquecidos também fazem parte do offboarding.

Revise:

• licenças compradas pelo MSP para o cliente;
• licenças do cliente administradas pelo MSP;
• assinaturas com renovação automática;
• domínios, DNS, certificados e hospedagem;
• serviços de backup, e-mail, segurança e nuvem;
• garantias e contratos com terceiros;
• cobranças finais, créditos ou consumo pendente;
• data exata de encerramento da cobrança recorrente.

Não cancele um recurso do cliente só porque aparece no seu cartão ou portal. Primeiro defina se será cancelado, transferido ou reatribuído — e quem aceita essa mudança.

8) Obtenha evidências e aceite, não apenas uma despedida

O registro de encerramento deve responder:

• O que foi concluído?
• O que não pôde ser concluído?
• Quais acessos foram revogados, transferidos ou rotacionados?
• Quais agentes continuam pendentes e por quê?
• Quais informações foram entregues?
• Quais dados serão mantidos e até quando?
• Quais riscos residuais o cliente aceitou?
• Quem executou e aprovou cada ação?

Use uma matriz final:

O registro não precisa ter vinte páginas. Precisa ter escopo, resultados, exceções, responsáveis e aceite.

9) Baixe e adapte o modelo

Preparamos uma planilha para executar o processo:

Baixar o checklist de offboarding de clientes MSP (.xlsx)

Ela inclui:

• 26 controles em seis fases;
• colunas para responsável, prazo, evidência e exceção;
• status com lista suspensa;
• progresso automático;
• abas ES, EN e PT;
• fontes oficiais e lembrete contratual.

Use como ponto de partida. Adicione os sistemas, fornecedores, prazos e aprovações reais de cada cliente.

FAQ: offboarding de clientes MSP

Quando o offboarding deve começar?

Assim que houver uma notificação válida e uma data de encerramento confirmada. A preparação pode começar antes; ações destrutivas ou de revogação devem respeitar o horário autorizado.

Todos os agentes devem ser desinstalados imediatamente?

Não antes de conciliar inventário, propriedade, conectividade e autorização. Alguns endpoints podem estar offline, em transição ou temporariamente gerenciados durante a entrega.

Bloquear uma conta encerra todas as sessões?

Nem sempre. Alguns aplicativos emitem seus próprios tokens ou cookies. Verifique a revogação de sessões dentro de cada plataforma crítica.

Por quanto tempo um MSP deve manter dados do cliente?

Não existe um período universal. Baseie-se no contrato, finalidade, sensibilidade, legislação e obrigações aplicáveis. Documente a data de exclusão.

O modelo substitui contrato ou aconselhamento jurídico?

Não. É uma ferramenta operacional. Adapte-a com orientação profissional quando houver requisitos legais, fiscais, regulatórios ou de privacidade.

Um encerramento profissional também importa

O onboarding conquista o cliente.

O offboarding mostra como você trabalha quando a relação termina.

Com o Lunixar RMM para MSPs, você centraliza inventário, estado dos endpoints, alertas e relatórios que ajudam a construir evidências. Um encerramento correto acrescenta o que nenhuma console decide por você: autorização, transferência, revogação, retenção e aceite.

Sem acessos esquecidos.

Sem agentes órfãos.

Sem dados guardados “por precaução”.