Outsourcing TI no elimina la responsabilidad de la empresa sobre sus propios riesgos
NIST plantea la tercerización como una extensión de capacidades, no como una transferencia total de responsabilidad.
NIST plantea la tercerización como una extensión de capacidades, no como una transferencia total de responsabilidad.
1. Tercerizar no significa dejar de gobernar
La empresa debe definir qué funciones entregará al proveedor.
También necesita conservar responsables internos capaces de tomar decisiones.
La noticia merece atención porque no se limita a una función aislada: cambia la forma en que una empresa puede plantear outsourcing ti no elimina la responsabilidad de la empresa sobre sus propios riesgos dentro de un entorno real de trabajo.
2. Responsabilidades que deben quedar dentro de la empresa
El proveedor forma parte del riesgo de terceros y debe evaluarse.
Alcance, accesos, tiempos, comunicación y continuidad deben quedar documentados.
Alcance, accesos, tiempos, comunicación y continuidad deben quedar documentados.
3. El proveedor como parte del riesgo de terceros
Un proveedor de outsourcing TI debería ampliar capacidades internas, no convertirse en una caja negra donde nadie sabe quién tiene acceso o cómo se toman decisiones.
En términos prácticos, el equipo técnico debería separar tres preguntas: qué hace la nueva capacidad, qué permisos necesita y qué ocurre cuando falla. Esa separación evita evaluar una tecnología únicamente por una demostración exitosa.
4. Alcance, accesos y escalamiento
Los acuerdos deberían definir alcance, tiempos de atención, escalamiento, seguridad, confidencialidad, documentación y responsabilidades de ambas partes.
Para una organización, el impacto puede aparecer en productividad, seguridad, continuidad, costos o capacidad de soporte. La prioridad dependerá del proceso afectado y de cuánto daño produciría una configuración incorrecta.
5. Qué debería decir un buen contrato de soporte
| Pregunta | Qué conviene revisar | Por qué importa |
|---|---|---|
| ¿Quién lo usa? | Usuarios, roles, cuentas de servicio y agentes autorizados | Reduce accesos innecesarios |
| ¿Qué datos toca? | Origen, destino, retención y clasificación de la información | Evita exposición o uso fuera de política |
| ¿Cómo se audita? | Logs, historial de acciones, alertas y responsable | Permite investigar errores e incidentes |
| ¿Qué pasa si falla? | Procedimiento manual, rollback y dependencia externa | Protege continuidad operativa |
| ¿Cuánto cuesta? | Licencias, consumo, infraestructura y soporte | Evita escalar una solución económicamente inviable |
6. Cómo medir al proveedor más allá del tiempo de respuesta
El valor sostenible aparece cuando el servicio deja conocimiento, métricas y procedimientos reutilizables además de resolver incidentes.
Una buena prueba piloto debería utilizar un caso real, un grupo limitado y métricas definidas antes de empezar. Así se puede comparar el proceso anterior con el nuevo y decidir si la mejora justifica ampliar el despliegue.
- Antes: documentar el proceso actual y sus tiempos.
- Durante: registrar errores, excepciones, costos y acciones manuales necesarias.
- Después: comparar resultados y decidir si se amplía, ajusta o descarta la implementación.
7. Qué debería quedar por escrito con un proveedor
- Servicios incluidos y exclusiones.
- Horarios de atención y canales oficiales.
- SLA de respuesta, atención y escalamiento.
- Accesos administrativos y proceso de baja.
- Tratamiento de información y confidencialidad.
- Documentación, inventarios y entrega de conocimiento.
- Procedimiento de continuidad si el proveedor no está disponible.
8. Recomendaciones para gestionar un MSP
- Verificar la disponibilidad real: confirmar región, edición, licencia o fase de despliegue antes de comunicarla como activa para todos.
- Empezar pequeño: utilizar un piloto controlado antes de habilitar la función de manera masiva.
- Definir propietario: una persona o área debe responder por configuración, costos y revisión periódica.
- Proteger datos y accesos: aplicar permisos mínimos y evitar entregar información sensible sin necesidad.
- Preparar reversión: documentar cómo volver al proceso anterior si la nueva capacidad genera fallos.
- Medir el beneficio: comparar tiempo, calidad, riesgo y costo antes y después.
adoptar la novedad únicamente cuando exista un caso de uso claro, controles definidos y una forma objetiva de comprobar que mejora el servicio.
NIST — Guía vigente consultada 04/09/2026.
https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/building-your-team
✍️ Artículo preparado por ARPYNET a partir de la fuente indicada. La fecha editorial de este post es 04/09/2026. Cuando la fuente original es anterior al día de publicación, el artículo se identifica expresamente como actualidad reciente, análisis vigente o cambio próximo.