El cliente pensó que lo hacía el MSP.
El MSP estaba esperando aprobación.
Nadie lo dejó por escrito.
Y la duda apareció justo cuando hubo que actuar.
> Descarga la matriz de responsabilidades MSP–cliente en XLSX. Incluye 30 controles, roles RACI, evidencia, frecuencias, estados y pestañas en español, inglés y portugués.
Una relación de servicios administrados no falla sólo por falta de herramientas. También falla cuando nadie puede responder con rapidez: ¿quién ejecuta, quién decide, quién aprueba el riesgo y qué evidencia debe quedar?
1) Empieza por quitar la frase “eso lo ve sistemas”
“Sistemas” no es un responsable.
Tampoco lo son “el proveedor”, “el cliente” o “el área correspondiente”. Cuando algo se detiene, esas frases obligan a descubrir el proceso mientras el reloj ya está corriendo.
NIST recomienda que, al contratar un proveedor de servicios administrados, se documenten el nivel de servicio, las responsabilidades y las expectativas. También aclara algo importante: externalizar trabajo no elimina la responsabilidad que conserva la empresa sobre sus sistemas y datos.
Por eso la matriz debe vivir junto al contrato y al SLA del MSP, pero responder una pregunta distinta:
- el contrato define la relación;
- el SLA define compromisos y tiempos;
- la matriz define quién interviene en cada actividad;
- el runbook explica cómo se ejecuta;
- el ticket conserva la evidencia de lo que ocurrió.
No intentes meterlo todo en un documento de cincuenta páginas. Haz que cada pieza tenga un trabajo claro.
2) Usa RACI, pero sin convertir la reunión en una clase de siglas
RACI funciona porque obliga a separar cuatro papeles:
- R — ejecuta: hace el trabajo y registra el resultado;
- A — aprueba: acepta la decisión, el riesgo o el cambio;
- C — consultado: aporta contexto antes de actuar;
- I — informado: necesita conocer el resultado, pero no detener el flujo.
Una misma parte puede ser R/A cuando ejecuta y también tiene autoridad para decidir dentro del alcance acordado. Por ejemplo, el MSP puede revisar alertas rutinarias, crear el ticket y cerrar una acción de bajo riesgo sin pedir permiso por cada clic.
Eso no significa que pueda decidir todo. Aislar un servidor, apagar una aplicación, aceptar una excepción de seguridad o incrementar un costo suele requerir a alguien del cliente con autoridad real.
La matriz descargable incluye columnas separadas para rol del MSP, rol del cliente y “quién aprueba o decide”. Así evitas una trampa común: poner una A en una celda sin nombrar a la persona o función que puede dar esa aprobación.
3) Define alcance y autorización antes de instalar agentes
La primera sección de la matriz no es técnica. Es de gobierno:
- servicios incluidos y excluidos;
- clientes, sedes y activos cubiertos;
- contactos autorizados;
- canales de escalamiento;
- cambios que modifican alcance o costo;
- fecha y responsable de la siguiente revisión.
Esto importa especialmente con un RMM. Tener capacidad técnica para acceder a un endpoint no equivale a tener autorización ilimitada para usarla. El artículo sobre uso autorizado de Lunixar RMM explica por qué el consentimiento, el alcance y la trazabilidad deben acompañar cualquier operación remota.
El mismo control aplica al onboarding de endpoints. Si el cliente esperaba 42 equipos y sólo hay 39 visibles, la matriz debe indicar quién concilia la diferencia, quién confirma el inventario y quién aprueba cualquier ampliación.
4) Reparte la operación diaria con evidencia mínima
Una buena matriz no dice solamente quién hace algo. También define cómo se demuestra que ocurrió.
| Actividad | MSP | Cliente | Evidencia mínima |
|---|---|---|---|
| Conciliar inventario | ejecuta | consulta y valida diferencias | exportación y lista de variaciones |
| Revisar alertas | ejecuta dentro del alcance | recibe escalamiento | ticket, acción y cierre |
| Aprobar ventana de mantenimiento | consulta | aprueba | calendario o ticket aprobado |
| Desplegar parches aprobados | ejecuta | aprueba política | resultado instalado, pendiente o fallido |
| Probar restauración | ejecuta | aprueba alcance | acta con tiempo y resultado |
| Renovar una licencia | prepara contexto | aprueba costo | autorización con monto y vigencia |
Conciliar inventario
ejecuta
consulta y valida diferencias
exportación y lista de variaciones
Revisar alertas
ejecuta dentro del alcance
recibe escalamiento
ticket, acción y cierre
Aprobar ventana de mantenimiento
consulta
aprueba
calendario o ticket aprobado
Desplegar parches aprobados
ejecuta
aprueba política
resultado instalado, pendiente o fallido
Probar restauración
ejecuta
aprueba alcance
acta con tiempo y resultado
Renovar una licencia
prepara contexto
aprueba costo
autorización con monto y vigencia
Observa la diferencia entre enviar una acción y verificar el resultado. Un parche no está cerrado porque salió una orden. Un agente no está instalado porque se descargó un archivo. Un respaldo no está validado porque el trabajo apareció en verde.
La evidencia debe ser proporcional al riesgo. Para una tarea rutinaria puede bastar el resultado en la consola. Para una restauración, un cambio crítico o una excepción, necesitas fecha, alcance, responsable, resultado y siguiente acción.
5) Separa respuesta técnica de decisiones de negocio
Los incidentes revelan rápido si la matriz sirve.
La guía conjunta de CISA y otras autoridades para proteger a MSPs y sus clientes recomienda coordinar controles como MFA, monitoreo y registros, acceso remoto, respuesta a incidentes y recuperación. Ninguno funciona bien si las dos partes descubren sus responsabilidades durante la emergencia.
Define de antemano:
- quién clasifica la alerta;
- quién recibe el primer escalamiento;
- quién puede aislar una compu;
- quién autoriza interrumpir un servicio crítico;
- quién contacta a la aseguradora o asesoría legal;
- quién informa a usuarios, dirección o terceros;
- quién conserva la cronología y la evidencia;
- quién declara cerrado el incidente.
El MSP puede contener una amenaza dentro de un runbook previamente aprobado. Pero una decisión con impacto de negocio necesita una autoridad del cliente localizable, incluyendo una alternativa fuera de horario.
Conecta esta sección con un playbook de respuesta a alertas y pruébala con un escenario sencillo: malware en una laptop, un servidor sin espacio o una cuenta administrativa bloqueada.
6) Trata pendientes y excepciones como decisiones con fecha
No todas las filas terminarán en “acordado”. Está bien.
Puede haber un servidor que no se puede reiniciar, una aplicación sin soporte, un usuario que necesita una excepción temporal o un servicio que quedó fuera del contrato. El problema no es tener excepciones. El problema es que nadie sepa quién las aceptó ni cuándo vencen.
Cada excepción debería indicar:
- riesgo o impacto comprendido;
- razón de negocio;
- control compensatorio, si existe;
- persona que aprueba;
- responsable de seguimiento;
- fecha de revisión o vencimiento;
- evidencia de cierre.
La plantilla usa estados separados: Por revisar, Acordado, Pendiente, Excepción aprobada y Fuera de alcance. También calcula cuántos controles están acordados para que la reunión no termine con una falsa sensación de avance.
7) Revisa la matriz durante todo el ciclo del cliente
La matriz no se firma una vez para después olvidarla en una carpeta.
Úsala en cuatro momentos:
- Onboarding: confirma alcance, accesos, contactos, activos y primeras políticas.
- Operación mensual: actualiza cambios, pendientes, proveedores y excepciones.
- Revisión con el cliente: presenta decisiones que necesitan presupuesto, prioridad o aceptación de riesgo junto con los reportes RMM para clientes y auditorías.
- Offboarding: revoca accesos, transfiere activos y registra aceptación con el checklist de cierre para clientes MSP.
Revisa también la matriz cuando cambie el contrato, el personal autorizado, una plataforma crítica, el alcance del respaldo o el proceso de incidentes.
Una fecha de “última actualización” no demuestra vigencia. La evidencia útil es una revisión donde alguien confirmó que los responsables todavía son correctos.
8) Descarga la matriz y adáptala con el cliente
La plantilla contiene 30 controles agrupados en:
- gobierno y alcance;
- identidad y acceso;
- monitoreo e inventario;
- parches y cambios;
- respaldos y recuperación;
- incidentes;
- datos y terceros;
- reportes y revisión;
- cierre del servicio.
Incluye filtros, listas desplegables, roles RACI, evidencia mínima, frecuencia, escalamiento, estado, próxima revisión y notas de excepción. Las pestañas ES, EN y PT permiten trabajar con clientes o equipos regionales sin mantener archivos separados.
Descargar matriz de responsabilidades MSP–cliente (.xlsx)
No la envíes en blanco esperando que el cliente la complete solo. Prepárala con tu alcance propuesto y úsala para conducir una conversación de decisiones.
Preguntas frecuentes
¿La matriz reemplaza el contrato o el SLA?
No. Es una herramienta operativa. El contrato establece obligaciones y el SLA define niveles de servicio; la matriz aterriza responsables, aprobaciones y evidencia. Adáptala con asesoría profesional cuando existan requisitos legales, fiscales, regulatorios o de privacidad.
¿El MSP debe ser responsable de todos los controles técnicos?
No necesariamente. Depende del alcance contratado, las capacidades del cliente, los proveedores involucrados y la autoridad delegada. No marques al MSP como responsable de una actividad que no puede ejecutar o verificar.
¿Puede una parte tener el rol R/A?
Sí, cuando ejecuta y también tiene autoridad para aprobar dentro de un alcance definido. Úsalo con cuidado en acciones que puedan interrumpir el negocio, aceptar riesgo o generar costo.
¿Cada cuánto debe actualizarse?
Como base, trimestralmente y siempre que cambien alcance, personal autorizado, activos críticos, proveedores, políticas, canales de escalamiento o contrato.
¿Qué pasa si el cliente no aprueba una responsabilidad?
Déjala como pendiente, registra el impacto, asigna un responsable de seguimiento y fija una fecha. No escondas la falta de decisión marcándola como fuera de alcance sin confirmación.
Menos zona gris. Más operación verificable.
Una matriz no evita todos los incidentes.
Evita algo más básico y costoso: perder tiempo descubriendo quién tenía que actuar.
Lunixar RMM puede aportar la evidencia operativa de inventario, estado de endpoints, alertas, parches y reportes. La matriz conecta esa evidencia con responsables, aprobaciones y decisiones humanas.
Conoce Lunixar RMM para MSPs y prueba hasta 5 dispositivos durante 14 días, sin tarjeta.
