Guía de decisión: Inhouse vs. Managed Services – Riesgos de personal y responsabilidades en el equipo de TI

Inhouse vs. Managed Services no es una cuestión puramente técnica: para responsables de TI, encargados de cumplimiento y responsables de seguridad, determina en gran medida los riesgos de personal, los límites de responsabilidad y las evidencias de auditoría. En esta decisión se contraponen la continuidad operativa, la conservación del conocimiento y la demostración jurídica frente a la escalabilidad, la flexibilidad de costes y el acceso a competencia especializada externa.

Por qué los riesgos de personal son centrales al elegir entre Inhouse y Managed Services

Los riesgos de personal afectan al deterioro de competencias, Single Point of Failure (SPoF), transferencia de conocimiento, rotación y disponibilidad operativa. Single Point of Failure se refiere a una única persona o rol cuyo fallo pone en riesgo considerable el funcionamiento. En los modelos inhouse la responsabilidad recae directamente en los equipos internos; en los Managed Services la responsabilidad suele permanecer contractualmente en el proveedor, pero la empresa sigue asumiendo el riesgo reputacional, de cumplimiento y de datos.

Lo decisivo es: la cuestión no es si existe responsabilidad — sino cómo se distribuye, documenta y verifica. Esta guía estructura la decisión en torno a gobernanza, operación, seguridad, costes y pasos concretos de implementación.

Resumen breve: diferencias clave desde la perspectiva de los riesgos de personal

• Inhouse: Control operativo total, el conocimiento permanece internamente, mayores costes de personal y mayor dependencia de personas clave internas.
• Managed Services: Acceso a experiencia externa, riesgo de retención de personal potencialmente menor, pero riesgos contractuales y menor influencia directa en la selección, la formación y la generación de evidencias.

Gobernanza: definir claramente las responsabilidades

La gobernanza describe reglas, roles y procesos de evidencia. En cada modelo debe establecerse una responsabilidad clara (p. ej. quién escala la respuesta a incidentes, quién otorga las autorizaciones de cambio) y registrarse evidencias de auditoría. Una herramienta habitual es la matriz RACI (Responsible, Accountable, Consulted, Informed). RACI asigna tareas a cuatro clases de rol y reduce las incertidumbres en la operación.

Ejemplo: RACI para respuesta a incidentes

La siguiente tabla RACI, copiable, es un ejemplo básico que debe adaptar a su organización.

Aktivität,Incident Owner (intern),Ops Team (intern),Managed Provider,Sicherheitsverantwortlicher,Geschäftsführung
Erkennung,R,A,C,I,I
Containment,R,A,C,C,I
Root Cause Analyse,A,R,C,C,I
Kommunikation an Stakeholder,I,I,R,A,A
Lessons Learned,A,R,C,C,I

Nota: ‚R‘ = Responsible (ejecutor), ‚A‘ = Accountable (responsable de la decisión), ‚C‘ = Consulted (a consultar), ‚I‘ = Informed (a informar).

Operacionalización: Operación, SLAs e interfaces

Un Managed Service no le libera automáticamente de la responsabilidad operativa. Son decisivos la definición de SLAs, las interfaces (APIs, sistemas de tickets, monitorización), y los roles para la escalación y el control de cambios. Verifique en particular:

• Métricas concretas de SLA: disponibilidad, MTTR (Mean Time To Repair), clases de fallo, mecánica de penalizaciones.
• Interfaces para datos de monitorización y auditoría: ¿Puede su equipo ver los registros directamente? ¿Se reenvían las alertas en paralelo a las herramientas internas?
• Flujo de cambios: ¿Quién autoriza los cambios en producción? ¿Cómo están reguladas las reversiones (rollbacks)?

Sin interfaces limpias surgen riesgos de personal ocultos: el equipo interno debe poder seguir técnicamente los procesos pese al outsourcing, de lo contrario pierde el conocimiento situacional.

Diseño de SLA: dos trampas concretas

Primera trampa: SLA centrado únicamente en la disponibilidad. Un proveedor puede garantizar disponibilidad, pero el tiempo hasta la RESTauración de la funcionalidad crítica para el negocio puede quedar poco claro. Segunda trampa: falta de transparencia en los trayectos de escalado. Defina una matriz de contactos con niveles de escalado vinculados a plazos temporales.

Seguridad y cumplimiento: responsabilidades, accesos y trazabilidad

La responsabilidad en materia de seguridad no puede externalizarse contractualmente en su totalidad. El Reglamento General de Protección de Datos (RGPD) o NIS2, por ejemplo, exigen que los operadores puedan demostrar cómo se gestionaron los derechos de acceso y cómo se notificaron los incidentes. Preguntas de auditoría esenciales:

• ¿Quién es el responsable del tratamiento frente al encargado del tratamiento? (Los términos se refieren a roles legales; el responsable del tratamiento determina los fines y los medios del procesamiento, el encargado actúa por encargo.)
• ¿Están los controles de acceso centralizados en su proveedor de identidad o en el proveedor gestionado? ¿Cómo se gestionan y auditan los accesos privilegiados (p. ej., claves SSH, cuentas de servicio)?
• ¿Cómo se documentan los incidentes de seguridad y existe una pista de auditoría aprovechable forensemente?

Plantilla de política práctica: revocación de privilegios en el offboarding

# Beispiel-Offboarding: Schritte (Checkliste für Administratoren)
# 1) Zugang sperren
usermod --expiredate 1 
# 2) SSH-Keys entfernen
rm /home//.ssh/authorized_keys
# 3) API-Credentials rotieren
# (Beispiel für HashiCorp Vault, falls verwendet)
vault write auth/approle/role//secret-id -force
# 4) Passwort zurücksetzen für gemeinsame Konten (Audit-Log-Eintrag)
# 5) Revoke SSO Tokens (Identity Provider)
# Admin-Konsole: revoke-session --user 

Documente cada paso con la fecha y hora y la persona que lo ejecutó; esto es esencial para las auditorías.

Gestión del personal: habilidades, planificación de sucesión y retención del conocimiento

Tanto en entornos internos como con Managed Services, la planificación de sucesión reduce los riesgos de SPoF. Medidas importantes son matrices de competencias, runbooks anuales, ejercicios de recuperación periódicos y job-shadowing. Una matriz de competencias muestra quién puede operar qué sistemas en qué nivel —idealmente con un plan de cross-training.

Planificación de sucesión: lista de verificación práctica

• Identifique roles críticos y documente las tareas básicas.
• Asigne al menos dos personas por rol crítico (titular y suplente).
• Realice transferencias de conocimiento trimestrales y ejercicios de RESTauración semestrales.
• Evalúe regularmente la curva de aprendizaje mediante tareas concretas (p. ej., RESTauración de un servicio desde backup).

Costes y riesgo: TCO, costes ocultos y equivalentes en FTE

Los Managed Services pueden reducir costes de personal directos, pero a menudo desplazan costes en forma de esfuerzo de integración, gestión contractual y controles de cumplimiento. Calcule la TCO no solo como la cuota mensual del proveedor, sino sumando:

• Esfuerzos internos para la gobernanza, revisiones y auditoría (p. ej., 0,2–0,5 FTE en complejidad media).
• Esfuerzo de integración (APIs, puentes IAM, flujos de monitorización).
• Recargos por riesgo (p. ej., costes por tiempos de RESTauración prolongados si las escaladas fallan).

Una fórmula simple de TCO:

TCO = Anbietergebühr + Integrationskosten + Governance-Aufwand + (RESTaurationskosten * Eintrittswahrscheinlichkeit)

Perspectiva de auditoría: generar y verificar evidencias

Para auditorías necesita pruebas técnicas: lista de accesos, registros de cambios (change-logs), informes SLA, informes de incidentes y constancias de formación. En contratos de servicios gestionados, el contrato debería regular los siguientes puntos:

• Acceso regular a logs en formato legible por máquina.
• Derechos de auditoría: los auditores internos o externos deben tener acceso a los procesos y evidencias relevantes.
• Procedimientos para la corrección de incumplimientos de cumplimiento y obligaciones de notificación dentro de plazos definidos.

Redacción contractual: cómo se regulan las responsabilidades en el contrato

Un contrato es más que el SLA y el precio. Componentes contractuales relevantes:

• Matriz de roles y responsabilidades (incl. referencia RACI).
• Definición de interfaces: espectro de APIs, feeds de monitorización, integraciones de ticketing.
• Cláusulas de acceso a datos y protección de datos, incl. listas de subprocesadores.
• Plan de salida y transición: devolución de datos, transferencia de conocimiento, apoyo en la transferencia de vuelta a operaciones internas (in-house) o a otro proveedor.

Particularmente importante es un plan de transición con entregables definidos: volcado de datos en formato estandarizado, runbooks transferidos, slots de formación y periodos de acompañamiento (shadowing).

Contenido mínimo de un hito de transición (ejemplo)

Milestone: Übergabe Produktivbetrieb
- Vollständige Datenexporte (Schema, Anwendungsdaten) in agreed format
- Zugriffsliste und Credential-Inventar übergeben
- Durchführung von 3 Knowledge-Transfer Sessions à 2 Stunden
- Dokumentierte Runbooks und Checklisten übergeben
- Support für 30 Tage nach Übergabe (Hotline + Ticketpriorität)

Guía de decisión: ¿Cuándo in-house y cuándo servicio gestionado?

La decisión depende de cinco factores: criticidad, requisitos de cumplimiento, habilidades internas disponibles, marco de costes y tiempo necesario para escalar.

• Prefiera in‑house si: existen fuertes requisitos regulatorios, la soberanía de los datos es imprescindible, o el negocio obtiene ventajas competitivas o de proceso por un know‑how específico.
• Prefiera servicios gestionados si: necesita escalar rápidamente, faltan conocimientos especializados, o puede externalizar componentes estandarizados (p. ej. gateways de correo, protección DDoS, almacenamiento de backups).

Árbol de decisión práctico (resumen)

1. ¿La función es críticamente regulatoria? (Sí → in‑house o contratos gestionados estrictos)
2. ¿Faltan habilidades internas y no pueden desarrollarse a corto plazo? (Sí → servicios gestionados)
3. ¿La soberanía de los datos o una baja latencia son críticas para el negocio? (Sí → in‑house)
4. ¿Puede garantizar contractualemente un plan de transición y acceso de auditoría? (No → no externalizar)

Implementación: medidas de integración y control en la externalización

Incluso con servicios gestionados debe establecer puntos de control:

• Monitoring‑mirroring: copia de métricas clave hacia sistemas internos.
• Ejercicios de mesa periódicos (table‑top exercises) para respuesta a incidentes con el proveedor.
• Revisiones de negocio trimestrales con revisión de KPIs (MTTR, tasa de éxito de cambios, incidentes de seguridad).
• Auditorías técnicas: entornos sandbox, tests de penetración, revisiones de control de accesos.

Ejemplo: lista de comprobación por línea de comandos para validación rápida de permisos de acceso

# Überprüfung, welche Service-Accounts auf einem Linux-Host sudo-Rechte haben
getent group sudo || true
# Liste sudoers-Dateien
ls -l /etc/sudoers.d
# Prüfen, welche SSH-Keys einem Systemkonto zugeordnet sind
grep -R "authorized_keys" /home /root || true

Estos checks forman parte de un playbook de auditoría que debería coordinar con el proveedor.

Inhouse vs. Managed Services: evaluar concretamente los riesgos de personal

Para una decisión fundamentada debe cuantificar y operacionalizar los riesgos de personal. Esto incluye la identificación de roles críticos, la evaluación de la rotación por edad, la disponibilidad de competencias en el mercado y los posibles tiempos de adquisición. Un modelo de valoración pragmático combina factores cualitativos con tres indicadores:

• SLE (Single Loss Expectancy): daño financiero estimado si un rol falla o se pierde conocimiento.
• ARO (Annualized Rate of Occurrence): probabilidad esperada de ocurrencia por año.
• ALE (Annualized Loss Expectancy) = SLE * ARO: pérdida anual esperada por ausencia de personal.

Ejemplo: si la ausencia de un administrador de sistemas provoca una interrupción de negocio de 20.000 EUR (SLE) y la probabilidad de ocurrencia es 0,1 por año (ARO), la ALE es 2.000 EUR. Use estos valores para fundamentar financieramente decisiones de outsourcing.

FTE‑Äquivalente und Steuerungsaufwand berechnen

En la práctica debe calcular cuántos FTE internos son necesarios para la gestión, auditoría e integración. Una orientación aproximada:

• Low‑Touch Managed Service (componente estandarizada): 0,1–0,3 FTE de gestión interna.
• Mid‑Touch (plataforma integrada con API/monitorización): 0,3–0,6 FTE.
• High‑Touch (función operativa crítica e integrada): 0,5–1,0+ FTE incluyendo esfuerzo de auditoría.

Estas estimaciones consideran el tiempo para revisiones, escaladas, auditorías y sesiones de transferencia de conocimiento. Fije estas estimaciones como partidas presupuestarias antes de la firma del contrato.

KPIs, Dashboards und Review‑Routinen für Providersteuerung

KPIs concretos hacen comparable el rendimiento del proveedor y reducen riesgos dependientes del personal mediante expectativas medibles. Métricas importantes:

• MTTR por clase de fallo (p. ej. P1, P2, P3).
• First‑Time‑Fix‑Rate: proporción de incidentes resueltos en la primera intervención.
• Change Success Rate: proporción de cambios exitosos sin rollback.
• Time to Knowledge Transfer: tiempo hasta que existe conocimiento documentado internamente.
• Audit‑Bereitschaft: número y completitud de logs auditados por periodo.

Técnicamente se recomienda un management‑dashboard con datos agregados de ticketing, monitorización y CI/CD. Configure informes automatizados para Quarterly Business Reviews (QBR) y obligue al proveedor a exportes en formato legible por máquina.

Sample SLA‑Klausel (kopierbar)

Cláusula SLA: Disponibilidad y escalado
1) Disponibilidad del servicio: 99,9% por mes calendario para la función X
2) Tiempos de respuesta:
   - P1: Reacción dentro de 15 minutos, solución o workaround dentro de 4 horas
   - P2: Reacción dentro de 1 hora, solución dentro de 24 horas
3) Matriz de escalado: Nivel 1 (Support Engineer) 15 min → Nivel 2 (Team Lead) 60 min → Nivel 3 (Service Manager) 4 h
4) Informes: CSV diario de incidentes, informe KPI semanal en formato JSON
5) Auditoría: acceso mensual a logs relevantes y reporte de PenTest trimestral

Regulatorische Anforderungen und Auditbeispiele

Con NIS2 u otros requisitos sectoriales, los auditores suelen exigir evidencias detalladas: quién accedió a qué datos y cuándo, qué cambios se aprobaron y que los procesos de offboarding son efectivos. Puntos de verificación para auditores:

• Existencia y aplicación de un procedimiento de control de accesos privilegiados.
• Evidencia de pruebas de RESTauración periódicas y sus resultados.
• Comprobantes de las sesiones de transferencia de conocimiento realizadas en el hito de transición.

Cláusula contractual: Derechos de auditoría (ejemplo)

Audit-Klausel:
Der Auftragnehmer gewährt dem Auftraggeber oder dessen beauftragten Prüfern vierteljährlich Zugang zu relevanten Betriebs- und Sicherheitslogs, Testfällen und Dokumentationen. Prüfungen dürfen nicht mehr als zweimal jährlich unangekündigt stattfinden und müssen in einem vereinbarten Test‑Sandbox-Scope erfolgen. Ergebnisse sind innerhalb 15 Arbeitstagen zu dokumentieren und zu beheben.

Onboarding, Offboarding und Trainingsplan (umsetzungsorientiert)

Un onboarding preciso reduce los esfuerzos de coordinación posteriores. Componentes clave:

• Integración técnica: API‑Keys, conexiones VPN, puentes IAM.
• Onboarding organizativo: responsabilidades, RACI, canales de comunicación.
• Transferencia de conocimiento: runbooks documentados, sesiones prácticas, periodos de shadowing.

Plan de formación (90 Tage)

Tag 0-14: Systemzugänge, Architektur-Review, Zugangstests
Tag 15-45: Hands-on-Workshops (Recovery, Failover), 2x Knowledge-Transfer Sessions
Tag 46-75: Shadowing im Live-Betrieb, Teilnahme an Incidents als Beobachter
Tag 76-90: Selbstständige Ausführung von Recovery-Aufgaben, Abschluss-Review und Zertifikat

Lista de verificación para la decisión (práctica)

• Análisis de criticidad de la función a externalizar
• Análisis de brecha de competencias y plan de formación
• Matriz de SLA y de escalamiento definida
• Matriz RACI creada y comunicada
• Acceso a auditoría y reporting asegurado contractualmente
• Plan de transición con entregables incorporado en el contrato
• Plan de emergencia y ejercicios de recuperación acordados
• Procesos de onboarding/offboarding asegurados técnica y organizativamente

Conclusión: Distribuir y documentar responsabilidades de forma consciente

La decisión entre Inhouse y Managed Services no es una disyuntiva absoluta, sino una evaluación organizativa. Los Managed Services ofrecen acceso a experiencia y escalabilidad, pero los riesgos de personal no desaparecen: cambian de forma. Lo decisivo son reglas de gobernanza claras, SLAs verificables, asignaciones RACI documentadas y un plan de transición que garantice conocimiento y evidencia de auditoría.

Medidas técnicas como Monitoring‑Mirroring, controles de acceso, ejercicios regulares de RESTauración y un offboarding riguroso son obligatorias en ambos modelos. Tome la decisión de forma estratégica, con un cálculo TCO sólido, riesgos de personal cuantificados (SLE/ARO/ALE) y KPIs operativos de control. Solo así puede reducirse el riesgo de personal de forma medible, tanto si los servicios se operan internamente como si se contratan externamente.

Para este tema también son importantes las responsabilidades de IT y el diseño de SLA. El texto contextualiza estos aspectos de manera comprensible y muestra qué es relevante en la operativa diaria.