Matriz de responsabilidades MSP–cliente: quem faz o quê

O cliente achou que o MSP faria.

O MSP estava esperando aprovação.

Ninguém colocou isso por escrito.

E a dúvida apareceu exatamente quando alguém precisava agir.

> Baixe a matriz de responsabilidades MSP–cliente em XLSX. Ela inclui 30 controles, papéis RACI, evidências, frequências, status e abas em português, espanhol e inglês.

Uma relação de serviços gerenciados não falha apenas por falta de ferramentas. Ela também falha quando ninguém consegue responder rápido: quem executa, quem decide, quem aceita o risco e qual evidência deve ficar?

1) Elimine “isso é com a TI” do processo

“A TI” não é um responsável.

“O fornecedor”, “o cliente” e “a área correspondente” também não são. Quando algo para, esses rótulos obrigam todos a descobrir o processo enquanto o relógio já está correndo.

O NIST recomenda documentar o nível de serviço, as responsabilidades e as expectativas ao contratar um provedor de serviços gerenciados. Também destaca um ponto importante: terceirizar o trabalho não elimina a responsabilidade que a empresa mantém sobre seus sistemas e dados.

Por isso, a matriz deve ficar ao lado do contrato e do SLA do MSP, mas responder a uma pergunta diferente:

• o contrato define a relação;
• o SLA define compromissos e prazos;
• a matriz identifica quem participa de cada atividade;
• o runbook explica como a atividade será executada;
• o chamado preserva a evidência do que aconteceu.

Não tente colocar tudo em um documento de cinquenta páginas. Dê a cada artefato uma função clara.

2) Use RACI sem transformar a reunião em uma aula de siglas

RACI funciona porque separa quatro papéis:

• R — executa: realiza o trabalho e registra o resultado;
• A — aprova: aceita a decisão, o risco ou a mudança;
• C — consultado: fornece contexto antes da ação;
• I — informado: precisa conhecer o resultado, mas não deve travar o fluxo.

Uma mesma parte pode ser R/A quando executa e também tem autoridade para decidir dentro do escopo acordado. Por exemplo, o MSP pode revisar alertas rotineiros, criar um chamado e encerrar uma ação de baixo risco sem pedir permissão para cada clique.

Isso não significa que ele possa decidir tudo. Isolar um servidor, desligar uma aplicação, aceitar uma exceção de segurança ou aumentar um custo normalmente exige alguém do cliente com autoridade real.

A matriz para download tem colunas separadas para o papel do MSP, o papel do cliente e quem aprova ou decide. Assim você evita uma armadilha comum: colocar um A em uma célula sem nomear a função que pode aprovar.

3) Defina escopo e autorização antes de instalar agentes

A primeira seção da matriz não é técnica. É de governança:

1. serviços incluídos e excluídos;
2. clientes, locais e ativos cobertos;
3. contatos autorizados;
4. canais de escalonamento;
5. mudanças que afetam escopo ou custo;
6. data e responsável pela próxima revisão.

Isso importa ainda mais com um RMM. Ter capacidade técnica para acessar um endpoint não é autorização ilimitada para usá-la. Nosso guia sobre uso autorizado do Lunixar RMM explica por que consentimento, escopo e rastreabilidade devem acompanhar qualquer operação remota.

O mesmo controle vale no onboarding de endpoints. Se o cliente esperava 42 equipamentos e apenas 39 aparecem, a matriz deve dizer quem concilia a diferença, quem confirma o inventário e quem aprova uma ampliação.

4) Divida a operação diária e defina evidência mínima

Uma boa matriz não diz apenas quem faz algo. Ela também define como o resultado será comprovado.

Observe a diferença entre enviar uma ação e verificar o resultado. Um patch não está encerrado porque um comando foi enviado. Um agente não está instalado porque um arquivo foi baixado. Um backup não está validado porque a tarefa ficou verde.

A evidência deve acompanhar o risco. Uma tarefa rotineira pode exigir apenas o resultado da console. Uma restauração, mudança crítica ou exceção precisa de data, escopo, responsável, resultado e próxima ação.

5) Separe resposta técnica de decisões de negócio

Incidentes revelam rapidamente quando a responsabilidade está fraca.

A orientação conjunta da CISA e de autoridades internacionais para proteger MSPs e seus clientes recomenda coordenação em torno de MFA, monitoramento e registros, acesso remoto, resposta a incidentes e recuperação. Nada disso funciona bem quando as duas partes descobrem suas responsabilidades durante a emergência.

Defina com antecedência:

• quem classifica o alerta;
• quem recebe o primeiro escalonamento;
• quem pode isolar um computador;
• quem autoriza a interrupção de um serviço crítico;
• quem contata a seguradora ou assessoria jurídica;
• quem comunica usuários, direção ou terceiros;
• quem preserva a linha do tempo e as evidências;
• quem declara o incidente encerrado.

O MSP pode conter uma ameaça conforme um runbook aprovado previamente. Uma decisão com impacto no negócio ainda precisa de uma autoridade do cliente que possa ser localizada, inclusive fora do horário comercial.

Conecte esta seção a um playbook de resposta a alertas e teste com um cenário simples: malware em um notebook, servidor sem espaço ou conta administrativa bloqueada.

6) Trate pendências e exceções como decisões com data

Nem todas as linhas terminarão como “Acordado”. Tudo bem.

Pode existir um servidor que não pode reiniciar, uma aplicação sem suporte, um usuário que precisa de uma exceção temporária ou um serviço fora do contrato. O problema não é ter exceções. O problema é não saber quem as aceitou ou quando vencem.

Cada exceção deve indicar:

• risco ou impacto compreendido;
• razão de negócio;
• controle compensatório, se existir;
• responsável pela aprovação;
• responsável pelo acompanhamento;
• data de revisão ou vencimento;
• evidência de encerramento.

O modelo separa Não revisado, Acordado, Pendente, Exceção aprovada e Fora do escopo. Ele também calcula quantos controles foram acordados para que a reunião não termine com uma falsa sensação de avanço.

7) Revise a matriz durante todo o ciclo do cliente

A matriz não deve ser assinada uma vez e esquecida em uma pasta.

Use-a em quatro momentos:

1. Onboarding: confirme escopo, acessos, contatos, ativos e políticas iniciais.
2. Operação mensal: atualize mudanças, pendências, fornecedores e exceções.
3. Revisão com o cliente: apresente decisões que precisam de orçamento, prioridade ou aceitação de risco junto com os relatórios RMM para clientes e auditorias.
4. Offboarding: revogue acessos, transfira ativos e registre o aceite com o checklist de offboarding de clientes MSP.

Revise também a matriz sempre que mudar o contrato, a equipe autorizada, uma plataforma crítica, o escopo de backup ou o processo de incidentes.

Uma data de “última atualização” não comprova vigência. Evidência útil é uma revisão em que alguém confirmou que os responsáveis continuam corretos.

8) Baixe a matriz e adapte com o cliente

O arquivo inclui 30 controles agrupados em:

• governança e escopo;
• identidade e acesso;
• monitoramento e inventário;
• patches e mudanças;
• backup e recuperação;
• incidentes;
• dados e terceiros;
• relatórios e revisão;
• encerramento do serviço.

Ele inclui filtros, listas suspensas, papéis RACI, evidência mínima, frequência, escalonamento, status, próxima revisão e notas de exceção. As abas PT, ES e EN permitem que equipes regionais trabalhem no mesmo arquivo.

Baixar matriz de responsabilidades MSP–cliente (.xlsx)

Não envie o arquivo vazio esperando que o cliente o complete sozinho. Preencha com o escopo proposto e use-o para conduzir uma conversa focada em decisões.

Perguntas frequentes

A matriz substitui o contrato ou o SLA?

Não. É uma ferramenta operacional. O contrato estabelece obrigações e o SLA define níveis de serviço; a matriz traduz isso em responsáveis, aprovações e evidências. Adapte-a com orientação profissional quando houver requisitos jurídicos, fiscais, regulatórios ou de privacidade.

O MSP deve ser responsável por todos os controles técnicos?

Não necessariamente. Depende do escopo contratado, das capacidades do cliente, dos fornecedores envolvidos e da autoridade delegada. Não atribua ao MSP uma atividade que ele não pode executar ou verificar.

Uma parte pode ser R/A?

Sim, quando executa o trabalho e também tem autoridade para aprovar dentro de um escopo definido. Use com cuidado em ações que podem interromper o negócio, aceitar risco ou gerar custo.

Com que frequência a matriz deve ser atualizada?

Trimestralmente é uma boa referência, e sempre que mudarem escopo, equipe autorizada, ativos críticos, fornecedores, políticas, canais de escalonamento ou contrato.

E se o cliente não aprovar uma responsabilidade?

Deixe como pendente, registre o impacto, atribua um responsável pelo acompanhamento e defina uma data. Não esconda a falta de decisão marcando como fora do escopo sem confirmação.

Menos zona cinzenta. Mais operação verificável.

Uma matriz não evita todos os incidentes.

Ela evita algo mais básico e caro: perder tempo descobrindo quem deveria agir.

Lunixar RMM pode fornecer evidências operacionais de inventário, estado dos endpoints, alertas, patches e relatórios. A matriz conecta essas evidências a responsáveis, aprovações e decisões humanas.

Conheça o Lunixar RMM para MSPs e teste até 5 dispositivos por 14 dias, sem cartão.