SLA vs SOW vs MSA: Cómo las PYMES comparan contratos de TI gestionada

TL;DR: Un contrato de TI gestionada suele ser tres documentos que trabajan en conjunto: el MSA establece las reglas legales base, el SLA define cómo se mide el soporte y el SOW define exactamente qué trabajo se realiza. Si no define desde el inicio responsabilidades, exclusiones y objetivos de tiempo, estará incorporando puntos únicos de falla en su modelo de soporte.

Desde un punto de vista operativo, la mayoría de las sorpresas en el soporte de TI no se deben a “malos técnicos”. Provienen de términos ambiguos, definiciones faltantes y contratos que miden lo incorrecto. Permítame explicarle los modos de falla y, después, le daré una lista de verificación repetible que puede usar para comparar propuestas de MSP de forma equivalente.

Por qué los detalles de un contrato de TI gestionada importan en la operación real

La tecnología es infraestructura. La infraestructura falla en los límites: traspasos, suposiciones y “pensamos que eso lo tenían ustedes”. Un contrato de TI gestionada debe eliminar esos límites al dejar explícitas las responsabilidades.

Esto es lo que realmente se rompe en entornos reales:

• Propiedad no definida (quién administra respaldos, MFA, endpoints, red, tickets con proveedores).
• Métricas de tiempo engañosas (respuesta rápida, resolución lenta).
• Minas de trabajo fuera de alcance (fuera de horario, proyectos, altas de usuarios nuevos, trabajo en sitio).
• Brechas de seguridad (el MSP asume que usted se encarga de políticas y capacitación; usted asume que el MSP se encarga de todo).
• Riesgo al finalizar el servicio (sin plan de salida documentado, credenciales, devolución de datos y eliminación de accesos).

Esto funciona bien hasta que deja de funcionar. Y cuando deja de funcionar, falla con fuerza, por lo general durante una interrupción, un incidente de seguridad o un cambio de liderazgo.

SLA vs SOW vs MSA: qué se supone que hace cada documento

Piense en estos tres documentos como un diagrama simple del sistema:

1. MSA (Master Services Agreement) = el chasis y las reglas de seguridad.
2. SLA (Service Level Agreement) = los medidores y alarmas (cómo se mide el desempeño).
3. SOW (Statement of Work) = la orden de trabajo (qué está incluido, qué está excluido y cómo se gestionan los cambios).

MSA (Master Services Agreement): la “capa base” legal y operativa

El managed services agreement (a menudo el MSA) define la relación. No es el lugar para lenguaje vago, porque controla lo que ocurre cuando las cosas se complican.

Cláusulas clave del MSA que impactan el soporte del día a día:

• Vigencia y terminación: renovación, periodos de aviso, cargos por terminación anticipada y qué ocurre con servicios prepagados.
• Limitación de responsabilidad: qué daños se excluyen y cómo se calculan los topes.
• Confidencialidad y manejo de datos: si usted obtiene derechos de auditoría y cómo se protegen los datos.
• Subcontratistas: quién puede acceder a sus sistemas y bajo qué controles.
• Propiedad de la documentación: diagramas de red, contraseñas, portales de administración y runbooks.

Consecuencia: si el MSA es débil en propiedad de la documentación y en el proceso de salida, puede terminar pagando para recuperar el control de su propio entorno. Si la disponibilidad (uptime) importa, este paso no es opcional.

SLA (Service Level Agreement): la capa de medición que evita discusiones

Un service level agreement debe definir objetivos medibles y el método para medirlos. Si el SLA es solo lenguaje de marketing, no tendrá resultados predecibles.

Como mínimo, su SLA debe definir:

• Horario de soporte (horario laboral, fuera de horario, feriados) y qué significa realmente “24/7”.
• Niveles de severidad (P1, P2, P3, P4) con ejemplos claros.
• Tiempo de respuesta vs tiempo de resolución (no son la misma métrica).
• Proceso de escalamiento (cuándo y cómo los tickets pasan a ingenieros senior).
• Cadencia de comunicación durante incidentes (actualizaciones cada X minutos para P1, por ejemplo).

SOW (Statement of Work): la capa de alcance que controla el costo

El statement of work es donde el alcance se vuelve real. Debe listar los servicios incluidos en lenguaje claro y definir qué activa cargos adicionales.

Secciones típicas del SOW que evitan sorpresas:

• Sistemas cubiertos: endpoints, servidores, firewalls, switches, Wi‑Fi, aplicaciones en la nube, software de línea de negocio.
• Cantidad de usuarios y dispositivos: cómo se facturan las adiciones y cuándo se realizan los ajustes (true-ups).
• Tareas de onboarding: discovery, documentación, despliegue de agentes, hardening base.
• Cambios estándar: alta de usuarios nuevos, restablecimiento de contraseñas, mapeo de impresoras, restablecimientos de MFA.
• Trabajo por proyecto: migraciones, renovaciones de red, iniciativas de cumplimiento y qué se considera un proyecto.

Consecuencia: si el SOW no define los límites del alcance, recibirá un “eso está fuera de alcance” en el peor momento posible. No porque el MSP sea malintencionado, sino porque el contrato no les dio margen operativo para actuar.

Términos del contrato de soporte de TI que importan: tiempo de respuesta vs tiempo de resolución

A la mayoría de los dueños de PYMES se les muestran tiempos de respuesta porque se ven bien en papel. En la práctica, el tiempo de resolución es lo que restablece la operación del negocio.

Tiempo de respuesta: acuse de recibo y triage

El tiempo de respuesta normalmente significa que el MSP reconoció el ticket, inició el triage o hizo el primer contacto. Una respuesta en 15 minutos es útil, pero no reabre su sistema POS, no restaura el correo ni recupera un servidor.

Tiempo de resolución: restablecimiento del servicio (y la letra pequeña)

El tiempo de resolución debe significar que el servicio se restablece a un estado acordado. Esté atento a estas exclusiones comunes:

• Dependencia de proveedores: “el reloj se detiene” mientras se espera a un ISP, proveedor SaaS o proveedor de hardware.
• Dependencia del cliente: espera de aprobaciones, accesos o una decisión.
• Disponibilidad de piezas: las reparaciones en sitio pueden depender de los tiempos de entrega del hardware de reemplazo.

Recomendación operativa: exija que el SLA defina “resuelto”, “workaround” y “restablecido”, y que especifique intervalos de actualización durante incidentes P1. Eso reduce la ambigüedad y el “pase de culpas”.

Exclusiones y trabajo fuera de alcance: donde los presupuestos se desangran

Todo contrato de TI gestionada tiene exclusiones. El problema no es que existan. El problema es que no se mapean a su entorno real.

Exclusiones comunes que las PYMES pasan por alto

• Soporte fuera de horario: puede facturarse por hora aunque usted pensara que tenía “TI gestionada”.
• Visitas en sitio: a veces limitadas por mes o facturadas con mínimos.
• Proyectos: cualquier cosa que implique planificación, migraciones o “cambio significativo”.
• Aplicaciones de terceros: contabilidad, apps dentales/médicas, ERPs por industria o herramientas propietarias.
• Cableado de red y electricidad: a menudo se excluyen explícitamente.

Cómo reducir sorpresas por trabajo fuera de alcance

1. Exija una matriz de alcance: liste sus sistemas en la columna izquierda y las responsabilidades en la parte superior (monitorear, parchear, administrar, respaldar, seguridad, enlace con proveedores).
2. Defina un proceso de cambios: qué cuenta como cambio estándar vs proyecto, y cómo se aprueban los estimados.
3. Incluya ejemplos por escrito: “el alta de un usuario nuevo incluye buzón, licenciamiento, MFA y enrolamiento del dispositivo” es mejor que “soporte a usuarios”.

Onboarding y offboarding: las dos fases que exponen puntos únicos de falla

El onboarding y el offboarding son donde usted descubre si un MSP opera con un proceso repetible o improvisa. Improvisar es divertido hasta que usted es quien lo paga.

Requisitos de onboarding (cómo se ve lo correcto)

• Discovery: inventario de usuarios, dispositivos, equipos de red y tenants en la nube.
• Control de credenciales: gestor de contraseñas seguro, cuentas break-glass y políticas de MFA.
• Hardening base: parcheo, protección de endpoints, limpieza de privilegios de administrador, logging.
• Documentación: diagrama de red, detalles del ISP, garantías, licencias y contactos de escalamiento.

Si utiliza Microsoft 365, exija claridad sobre la administración del tenant, cambios de licenciamiento y valores predeterminados de seguridad. Como referencia, Microsoft documenta expectativas de salud del servicio y continuidad aquí: Documentación de salud del servicio y continuidad de Microsoft 365.

Requisitos de offboarding (no negociables para el control de riesgos)

• Devolución de credenciales y eliminación de accesos: cuentas admin, claves API, herramientas RMM y acceso VPN.
• Devolución de datos: documentación, configuraciones, acceso a respaldos y custodia de claves de cifrado (si aplica).
• Soporte de transición: periodo razonable de traspaso y lenguaje de cooperación.

Consecuencia: sin términos de offboarding, puede heredar herramientas huérfanas, cuentas admin desconocidas y brechas de monitoreo. Eso se convierte en un pasivo de seguridad de inmediato.

Responsabilidades de ciberseguridad: defina la propiedad o acepte el riesgo

La ciberseguridad está llena de modelos de responsabilidad compartida. Responsabilidad compartida sin un responsable por escrito es solo un futuro informe de incidente.

Qué asignar explícitamente en el contrato

• Identidad y acceso: aplicación de MFA, acceso condicional (si se usa), política de contraseñas, controles de cuentas admin.
• Seguridad de endpoints: herramientas de antivirus/EDR, respuesta a alertas, acciones de aislamiento y pasos de remediación.
• Parcheo: sistema operativo, aplicaciones de terceros y firmware cuando aplique.
• Seguridad de correo electrónico: protección contra phishing, políticas de cuarentena y flujo de reporte por parte del usuario.
• Concientización en seguridad: quién imparte la capacitación, quién registra la finalización y cómo se manejan las excepciones.
• Respuesta a incidentes: qué está incluido, qué es facturable y tiempos de activación.

Como guía base a la que las PYMES pueden alinearse, CISA mantiene recursos prácticos aquí: Recursos de ciberseguridad de CISA para pequeñas empresas.

Requisitos de cumplimiento: los contratos deben respaldar auditorías, no generar hallazgos

Si tiene requisitos de cumplimiento (HIPAA, PCI DSS, CJIS o requisitos contractuales de seguridad), su contrato de TI gestionada debe respaldar la recopilación de evidencias y la asignación de controles.

Términos contractuales a solicitar en entornos impulsados por cumplimiento

• Logging y retención: qué se registra, por cuánto tiempo se conserva y quién puede acceder.
• Gestión de vulnerabilidades: cadencia de escaneo, plazos de remediación y manejo de excepciones.
• Alineación de políticas: quién redacta las políticas, quién las hace cumplir y dónde se almacenan.
• Soporte de auditoría: qué horas están incluidas, qué es facturable y tiempos de respuesta a solicitudes del auditor.

Consecuencia: si el MSP no puede proporcionar evidencia bajo demanda, puede fallar auditorías incluso si existen los controles técnicos. El papeleo es parte del sistema.

Lista de verificación de contrato con MSP: compare propuestas de TI gestionada de forma equivalente

Use esta lista de verificación de contrato con MSP para normalizar propuestas. Su objetivo es servicio predecible, costo predecible y cero puntos únicos de falla ocultos.

1) Lista de verificación de alcance y cobertura

• Lista de usuarios, dispositivos, servidores y equipos de red cubiertos
• Canales de soporte incluidos (teléfono, email, portal) y horario de soporte
• Reglas de soporte en sitio, cargos de desplazamiento y incrementos mínimos facturables
• Exclusiones explícitas y la tarifa por hora/proyecto para trabajo fuera de alcance

2) Lista de verificación de medición del SLA

• Definiciones de severidad con ejemplos vinculados a sus sistemas de negocio
• Objetivos de tiempo de respuesta y objetivos de resolución/restablecimiento
• Ruta de escalamiento y roles nombrados (mesa de ayuda, sysadmin, seguridad)
• Cadencia de comunicación durante incidentes P1

3) Lista de verificación de seguridad y respaldos

• Quién es responsable de la aplicación de MFA y de los controles de acceso administrativo
• Responsabilidad de protección de endpoints (monitoreo, respuesta, remediación)
• Alcance de respaldos: qué se respalda (servidores, Microsoft 365, endpoints), con qué frecuencia y retención
• Alcance de restauración: pruebas de restore, objetivos RTO/RPO y qué se considera un evento de recuperación ante desastres facturable

4) Lista de verificación de coordinación con proveedores y gestión de terceros

• Responsabilidades de troubleshooting con ISP y VoIP
• Límites de soporte para aplicaciones de línea de negocio
• Quién abre y gestiona tickets con proveedores, y cómo se factura el tiempo

5) Lista de verificación de onboarding y offboarding

• Cronograma de onboarding y entregables (documentación, herramientas, baselines)
• Gestor de contraseñas y modelo de custodia de credenciales
• Entregables de offboarding (exportación de documentación, eliminación de accesos, devolución de datos)

Servicios de TI gestionada en Palm Beach County: realidades locales que debe incluir en el contrato

Las PYMES en Palm Beach County suelen tener una combinación de usuarios en oficina, personal remoto y flujos de trabajo impulsados por cumplimiento. El contrato debe reflejar esa realidad, no una plantilla genérica.

Si opera en West Palm Beach, Palm Beach Gardens, Jupiter, Lake Worth, Boynton Beach, Delray Beach, Wellington, Royal Palm Beach o Boca Raton, pregunte específicamente por:

• Expectativas de respuesta en sitio y qué activa un despacho en sitio
• Planificación ante huracanes y eventos de energía: cobertura de UPS, apagado controlado y runbooks de recuperación
• Redes multiubicación: VPN, conectividad site-to-site y opciones de failover de ISP

Para comparar opciones localmente, comience con nuestro resumen de servicios de TI para empresas, y luego profundice en servicios de TI gestionada para PYMES. Si Microsoft 365 es central para sus operaciones, incluya por escrito la administración del tenant y las responsabilidades de seguridad mediante administración y soporte de Microsoft 365. Para reducir riesgos, mapee la propiedad de seguridad usando nuestros servicios de ciberseguridad para empresas como modelo de referencia.

Qué preguntar a un MSP antes de firmar

Estas preguntas están diseñadas para revelar puntos de falla ocultos:

1. Muéstreme las exclusiones exactas y tres ejemplos de trabajo fuera de alcance que probablemente enfrentaremos.
2. Defina “resolución” para una caída P1 y explique cómo se manejan los retrasos de proveedores.
3. Quién es responsable de los respaldos y las restauraciones, y con qué frecuencia prueban las restauraciones?
4. Quién es responsable de las decisiones de ciberseguridad (MFA, privilegios admin, excepciones de parcheo) y cómo se aprueban las excepciones?
5. Cómo es el offboarding y qué documentación recibimos al salir?

En la práctica, un buen MSP responderá esto sin improvisar. Si las respuestas son vagas, espere resultados vagos.