La planificación de sucesión para roles de TI críticos es, en muchas empresas, un tema de operaciones y cumplimiento subestimado: mientras los sistemas funcionen de forma estable, una sola persona clave actúa como «atajo» para el conocimiento, los accesos y las decisiones. Si esa persona falta (renuncia, enfermedad, ausencia prolongada, conflicto), un asunto de personal se convierte rápidamente en un problema de disponibilidad, seguridad y costes. Es especialmente crítico en roles que intervienen profundamente en identidades, claves criptográficas, Backup/RESTore, segmentos de red, Cloud-Tenants, bases de datos o soluciones de software cercanas al proceso.
Esta contribución muestra un enfoque práctico para identificar roles de TI críticos, evaluar los riesgos de forma realista y garantizar la continuidad mediante medidas aplicables. El foco está en la gobernanza, las consecuencias operativas, la perspectiva de auditoría, las responsabilidades y artefactos concretos (Runbooks, modelos de acceso, listas de comprobación de traspaso). El objetivo no es «más documentación por el mero hecho de documentar», sino una operación sólida que funcione también ante cambios de personal o ausencias.
Planificación de sucesión para roles de TI críticos en la práctica
En TI, las personas clave a menudo no surgen porque alguien sea «insustituible», sino porque los riesgos se acumulan durante años sin ser detectados: sistemas con historia, soluciones históricas no estandarizadas, falta de estandarización, presión de tiempo en la operación diaria. Los patrones típicos son:
- Single Point of Knowledge: El conocimiento sobre decisiones de arquitectura, configuraciones especiales, arranque de recuperación o interfaces recae en una sola persona.
- Single Point of Access: Accesos de administrador, Token, API-Keys, HSM-/KMS-Policies o cuentas Break-Glass no están regulados de forma que permitan el trabajo en equipo.
- Single Point of Decision: Aprobaciones para cambios, medidas de emergencia o excepciones de seguridad dependen de una persona, sin suplencia ni criterios documentados.
Las consecuencias inmediatas son previsibles: tiempos de recuperación más largos (RTO, «Recovery Time Objective») y mayores pérdidas de datos (RPO, «Recovery Point Objective») en caso de incidente, mayor tasa de errores en los cambios, soluciones alternativas arriesgadas y, en auditorías, falta de evidencia de que las funciones, responsabilidades y controles funcionan en la operativa diaria.
Definir correctamente roles de TI críticos: rol vs. persona vs. responsabilidad del sistema
Un tropiezo frecuente: las empresas confunden el título del puesto con el rol. Para un análisis de riesgos sólido debe separarse:
- Rol: conjunto de tareas, facultades y responsabilidades (p. ej., «Directory-Services-Administrator»).
- Persona: ocupación concreta (p. ej., «M. Mustermann»).
- Responsabilidad del sistema: qué sistema/servicio se responsabiliza (p. ej., «Entra ID / Active Directory», «ERP-Schnittstellenplattform», «infraestructura de Backup»).
Un rol es crítico cuando su ausencia pone en peligro el cumplimiento de procesos de negocio o requisitos de seguridad. Esto es especialmente cierto donde dependen identidades, permisos, criptografía, integridad de datos o los procesos de recuperación.
Ejemplos de roles frecuentemente críticos en la operación
- Identity & Access Management (IAM): gestión de identidades, roles, MFA, Conditional Access, aprovisionamiento.
- Privileged Access Management (PAM): control de accesos privilegiados, Session-Recording, procesos Break-Glass.
- Responsabilidad de Backup/RESTore: no «Backup läuft», sino «RESTore está ensayado y es demostrable».
- Operación de bases de datos: Backup/Recovery, rendimiento, permisos, cifrado, ventanas de mantenimiento.
Para soluciones empresariales digitales también es importante: ¿quién puede intervenir ante fallos en interfaces, flujos de datos o procesos de scheduler sin generar «efectos secundarios»? No solo son críticos los administradores, sino a menudo también los responsables de operación con conocimiento del dominio sobre procesos y calidad de datos.
Análisis de riesgo para roles de TI críticos: un modelo de scoring práctico
Un análisis de riesgo sensato debe cumplir dos objetivos: debe priorizar (por dónde empezar) y debe ser apto para auditoría y toma de decisiones (por qué se evaluó así). En la práctica probó ser efectivo un scoring basado en Impacto (afectación) y Exposición (probabilidad / grado de dependencia).
Criterios de Impacto (afectación ante la pérdida de la función)
- Interrupción del servicio: ¿Qué servicios críticos quedan fuera, durante cuánto tiempo y con qué costes secundarios?
- Impacto en seguridad: Respuesta a incidentes demorada, falta de rotación de claves, privilegios no controlados.
- Cumplimiento/Legal: Incumplimiento de controles internos, falta de evidencias, plazos en obligaciones de notificación.
- Riesgo de datos: Peligro de pérdida de datos, RESTauración incompleta, problemas de integridad.
Criterios de Exposición (probabilidad / dependencia)
- Bus-Factor: ¿Cuántas personas pueden ejecutar hoy la función de forma real (no teórica)?
- Dependencia de acceso: ¿Se gestionan contraseñas/tokens/keys de forma colaborativa o están ligadas a personas?
- Grado de documentación: ¿Existen runbooks y documentación del sistema con estado actualizado?
- Nivel de ensayo: ¿Se ha probado la vía de emergencia (RESTauración, conmutación por error, Break-Glass) en los últimos 6–12 meses?
Plantilla de ejemplo para un registro de riesgos por rol
Para la dirección de TI y auditoría, un registro uniforme es más útil que documentos aislados. Un esquema compacto:
- Rol / Servicio / Sistema(s)
- Designación titular y sustituto
- Impacto (1–5) y justificación
- Exposición (1–5) y justificación
- Riesgo (Impacto × Exposición) y prioridad
- Controles/Medidas, Responsable, Plazo, Evidencia
Registro de riesgos por rol (campos mínimos)
- Rol:
- Servicios/Sistemas afectados:
- Primario / Suplente:
- Accesos críticos (PAM/IAM/Break-Glass):
- Runbooks/Docs (ubicación, estado, fecha de revisión):
- Impacto (1-5) + Justificación:
- Exposición (1-5) + Justificación:
- Puntuación de riesgo:
- Medidas (breve):
- Responsable (Owner):
- Fecha de vencimiento:
- Evidencia/Prueba (enlace/artefacto):
Importante: “Evidence” no significa solo un documento, sino la prueba de que un proceso se practica realmente (p. ej., el registro de un ejercicio de RESTauración, aprobaciones de cambios, análisis de accesos). Precisamente en eso fallan muchas conversaciones de auditoría.
Catálogo de medidas: la continuidad se construye desde accesos, conocimiento, procesos y ejercicios
La planificación de sucesión se vuelve sostenible cuando las medidas no actúan de forma aislada. Cuatro palancas son decisivas: modelos de acceso, artefactos de conocimiento, procesos operativos y ejercicios.
1) Hacer que los accesos sean aptos para el equipo: PAM, Break-Glass y material de claves
Muchas interrupciones se agravan porque los accesos privilegiados dependen de personas. El objetivo es un modelo que garantice “al menos dos personas operativas”, sin debilitar los controles de seguridad.
- Privileged Access Management (PAM): las cuentas privilegiadas no deben usarse como “cuentas personales permanentes”, sino con límite temporal, trazables y, idealmente, con registro de sesiones.
- Break-Glass: acceso de emergencia para incidentes graves, estrictamente controlado (autorización, alerta, revisión posterior). Break-Glass no debe convertirse en el “camino normal”.
- Secrets Management: API-Keys, certificados, tokens y secretos de configuración deben almacenarse en bóvedas gestionadas con rotación, no en gestores de contraseñas personales ni en tickets.
Componente de la política (versión corta): Accesos privilegiados
1. Los accesos de administrador se realizan a través del flujo de trabajo PAM (Just-in-Time/Just-Enough-Access).
2. Las cuentas Break-Glass están separadas, protegidas por MFA, almacenadas en la bóveda y desencadenan alertas.
3. Cada uso de accesos privilegiados genera un ticket de revisión (¿Quién? ¿Por qué? ¿Qué cambios?).
4. Los secretos (Keys, Tokens, Certificados) se almacenan de forma centralizada, con rotación documentada y un owner.
Desde el punto de vista operativo y de auditoría, la ventaja es clara: reducen la dependencia de personas clave en TI sin ampliar el acceso. En su lugar, lo hacen más controlado y comprobable.
2) Operacionalizar la transferencia de conocimiento: Runbooks, documentación del sistema, “Known Bad States”
El traspaso de conocimiento rara vez fracasa por falta de voluntad, sino por falta de formatos. Para roles críticos se necesitan pocos, pero obligatorios, artefactos:
- Runbooks: secuencias de pasos para tareas recurrentes o críticas (reinicio/failover, RESTore, cambio de certificados, emergencias de usuarios).
- Documentación del sistema: dependencias, flujos de datos, interfaces, contactos de operación, ventanas de mantenimiento, monitorización/alertas, rutas de emergencia.
- „Known Bad States“: estados de fallo documentados que se produjeron en el pasado, incluyendo su detección (síntomas) y las contramedidas. En la práctica esto suele ser con frecuencia más valioso que textos de arquitectura perfectos.
Para que la documentación no quede obsoleta, debe estar vinculada a eventos operativos reales: cada incidente mayor y cada cambio relevante genera una revisión de la documentación (pequeña, pero obligatoria). Aquí se puede acoplar de forma limpia a la gobernanza de cambios existente.
3) La sustitución es más que „puede encargarse durante las vacaciones“
Una sustitución solo se considera fiable cuando se cumplen tres condiciones:
- Acceso: la sustitución puede actuar realmente en caso de emergencia (PAM/privilegios/rutas de emergencia).
- Competencia: la sustitución ha ejecutado las tareas de forma práctica (no solo „haber leído“).
- Capacidad de decisión: la sustitución puede aprobar cambios/medidas de emergencia dentro del marco definido.
Si falta alguna de ellas, surge una zona gris peligrosa: la sustitución figura en el organigrama, pero la operación sigue dependiendo del responsable primario.
4) Planificar ejercicios: pruebas de RESTauración, ejercicios tabletop, simulacros on-call
La continuidad no es demostrable sin ejercicios. Para roles críticos de TI son pragmáticos tres tipos de ejercicios:
- Validación de RESTauración: recuperación de sistemas y datos críticos – idealmente en un entorno aislado, con cronometraje y resultado documentado.
- Ejercicio tabletop: simulación de un escenario (p. ej., fallo de IAM, administrador comprometido, pérdida de claves). El resultado deben ser lagunas concretas en el procedimiento, no „aprendizajes de PowerPoint“.
- Simulacro on-call: pruebas breves y controladas (p. ej., cadena de alarmas, acceso mediante break-glass, vías de contacto). Objetivo: que la organización reaccione, no solo una persona.
Gobernanza y responsabilidades: RACI, SoD y derechos de decisión
La planificación de sucesiones suele fracasar por responsabilidades poco claras. Aquí son centrales dos conceptos:
- RACI (Responsible, Accountable, Consulted, Informed): aclara quién ejecuta, quién asume la responsabilidad, quién se consulta y quién se informa.
- SoD („Segregation of Duties“, separación de funciones): reduce los riesgos de fraude y manipulación al evitar que actividades críticas queden en una sola mano (p. ej., desarrollo, aprobación y acceso productivo).
Para las auditorías es especialmente relevante que „Accountable“ no se quede en abstracto. En roles críticos la responsabilidad debe poder remitirse a un nivel directivo capaz de fijar prioridades (tiempo para las transferencias, presupuesto para PAM, aprobaciones para formaciones y ejercicios).
RACI mínimo para roles críticos de TI (plantilla)
RACI (plantilla mínima)
- Service Owner (funcional/negocio): Accountable por la disponibilidad del servicio y la aceptación del riesgo
- Technical Owner (IT): Responsible por la operación, cambios, runbooks, monitorización
- Security/ISMS: Consulted en controles, permisos, registro (logging), procesos de incidentes
- Compliance/Audit: Informed sobre evidencia, desviaciones, estado de las medidas
- Sustitución: Responsible en el caso de sustitución definido (con límites claros)
Importante es la interfaz entre la dirección de TI, Seguridad y Compliance: si los riesgos se aceptan de forma consciente (p. ej. no hay disponible un segundo administrador de bases de datos a corto plazo), eso debe documentarse como decisión de riesgo —incluyendo medidas compensatorias (p. ej. ejercicios reforzados de monitorización y RESTauración).
Perspectiva de auditoría: qué evidencias esperan típicamente los auditores
Independientemente de si se guía por ISO 27001, sistemas de control internos o requisitos sectoriales: los auditores rara vez se limitan al papel. Comprueban si los controles funcionan en la práctica y si la empresa mantiene la capacidad de gestión ante cambios de personal.
Artefactos típicos de evidencia en el contexto de la planificación de sucesión:
- Matriz de roles y permisos para sistemas críticos (incl. ciclo de revisión y aprobaciones).
- Registros de accesos privilegiados (logs de PAM, revisiones Break-Glass, referencia a tickets).
- Runbooks con fecha de revisión y actualización trazable tras cambios/incidentes.
- Protocolos de ejercicios de RESTauración con tiempos medidos, desviaciones y medidas.
- Evidencias de onboarding/offboarding: revocación de accesos, transferencia de responsabilidades, devolución de hardware/token.
- Evidencias de formación/competencia para roles relevantes para la seguridad o la operación (no como promoción de certificados, sino como prueba de competencia).
Si construye la preparación para auditorías, vale la pena vincularla con la documentación sistemática existente (campos obligatorios, metadatos, lógica de revisión). Así reduce considerablemente el esfuerzo por auditoría, porque las evidencias no tienen que buscarse de nuevo cada vez.
Lógica de costes y esfuerzos: lo que realmente „cuesta“ la planificación de sucesión
En las decisiones sobre planificación de personal y continuidad surge rápidamente la cuestión de los costes. Prácticamente debe distinguir entre costes de implementación únicos y costes operativos recurrentes:
- Implementación: modelo de roles/RACI, registro de riesgos, plantillas de runbook, configuración de PAM/Secrets, ejercicios iniciales.
- Operativo: revisiones (permisos, documentación), ejercicios periódicos, onboarding/offboarding, formación continua, planificación de capacidad para suplencias.
El error más común es considerar solo los „costes de herramientas“ e ignorar el esfuerzo operativo. A la inversa: si unifica procesos (la revisión de cambios genera actualización de documentación, PAM genera tickets de revisión), los costes recurrentes disminuyen porque la continuidad queda integrada en la operación normal.
Ayuda para la decisión: ¿invertir o aceptar el riesgo?
Si debe establecer prioridades, utilice una lógica de decisión sencilla:
- Alto impacto + alta exposición: actuar de inmediato (accesos, suplencias, runbooks, ejercicios).
- Alto impacto + exposición media: planificar medidas, definir la compensación (monitorización, apoyo externo, escalación clara).
- Impacto medio + alta exposición: priorizar la estandarización y documentación, depurar accesos.
- Bajo impacto: documentar de forma mínima, pero no „olvidar“ (los roles cambian).
Importante para la dirección y compliance: la aceptación de riesgo es una decisión con responsabilidad. Requiere justificación, un plazo temporal y un plan para reducir el riesgo.
Implementación en 90 días: un plan realista para la dirección de TI
Un inicio pragmático evita que la planificación de sucesión quede como un proyecto descomunal. Un plan de 90 días puede ser así:
Fase 1 (Días 1–20): Crear transparencia
- Identificar servicios críticos (a partir de BCM, catálogo de servicios, historial de incidentes).
- Asignar roles y sistemas críticos, registrar el bus factor.
- Crear registro de riesgos por rol, priorizar los 10 principales riesgos.
Fase 2 (Días 21–60): Asegurar accesos y rutas de emergencia
- Definir claramente el procedimiento Break-Glass (aprobación, alertas, revisión).
- Establecer PAM/gestión de secretos para los servicios principales (como mínimo para niveles admin y root de la nube).
- Crear un runbook mínimo para los servicios principales (RESTauración, failover, certificados, identidades).
Fase 3 (Días 61–90): Capacitar y ejercitar a las sustituciones
- Nombrar suplentes y definir un plan de habilitación (tareas concretas, shadowing, ejercicios).
- Realizar al menos un ejercicio de RESTauración y un ejercicio tabletop.
- Establecer el archivo de evidencias y el ritmo de revisión (p. ej., trimestral).
Importante: Ya tras la Fase 2 dispondrá de riesgos reducidos de forma medible, porque los accesos y las rutas de emergencia dejarán de depender de personas individuales. La Fase 3 garantiza que todo no quede solo „teórico“.
Listas de verificación y plantillas: utilizables de inmediato para „Personale e specialisti“
Lista de verificación: detección de riesgos por personal clave en TI
- ¿Existen sistemas para los que solo una persona tiene derechos de administrador?
- ¿Hay secretos críticos para producción cuya ubicación/rotación no está gestionada de forma central?
- ¿Hay procesos de RESTauración que funcionan solo „a demanda“?
- ¿Existen reglas de firewall/red cuya lógica no está documentada?
- ¿Hay actividades recurrentes sin runbook (ventanas de parcheo, renovación de certificados, emergencias de usuarios)?
- ¿Depende la aprobación de cambios o la decisión sobre incidentes de una sola persona?
- ¿Faltan ejercicios tabletop o de RESTauración con acta/protocolo?
Lista de verificación: requisitos mínimos para runbooks de sistemas críticos
- Objetivo y desencadenante (¿cuándo aplicar?)
- Requisitos previos (accesos, herramientas, ventana de mantenimiento, dependencias)
- Secuencia de pasos con puntos de control (¿cómo identifico éxito/fracaso?)
- Rutas de rollback y escalación (¿quién se involucra y cuándo?)
- Evidencias: ¿qué logs/tickets/capturas se almacenan?
- Fecha de revisión y propietario
Plantilla: traspaso en cambios de rol (on-/offboarding para roles críticos)
Protocolo de entrega (rol crítico de TI)
1. Alcance de responsabilidad (sistemas/servicios, ventanas de mantenimiento, SLAs/SLOs):
2. Vías de acceso (PAM, acceso de emergencia, tokens, certificados, rutas del cofre):
3. Operación (monitorización, enrutamiento de alertas, fallos conocidos, límites de capacidad):
4. Cambios (roadmap actual, cambios abiertos, deuda técnica, dependencias):
5. Seguridad/Compliance (controles, revisiones, hallazgos abiertos, plazos):
6. Runbooks/Docs (enlaces, estado, próximas fechas de revisión):
7. Ejercicios (último ejercicio de RESTauración/tabletop, resultados, medidas):
8. Personas de contacto internas/externas (contratos, guardias, escalación):
9. Cierre: revocación de derechos antiguos, entrega confirmada, fecha/sign-off
Anti-patterns típicos y cómo evitarlos
Algunos patrones aparecen una y otra vez en la práctica y hacen que la planificación de sucesión «exista», pero que en caso real no funcione:
- Documentación sin acceso: existen runbooks, pero los suplentes no tienen acceso a sistemas o cofres. Solución: aclarar primero las vías de acceso y luego documentarlas.
- La herramienta sustituye al proceso: PAM/CMDB/Wiki está implementado, pero no se realizan revisiones. Solución: ritmos claros de revisión y responsables, vinculados a cambios/incidentes.
- Suplencia como actividad secundaria: sin asignación de tiempo la función nunca se aprende en la práctica. Solución: planificar tareas concretas de capacitación y medirlas.
- Acceso de emergencia como acceso permanente: el Break-Glass se convierte en un atajo. Solución: alarmas + revisión posterior obligatoria, y si procede bloqueos técnicos.
- «Lo tenemos en la cabeza»: el conocimiento histórico no es auditable ni escalable. Solución: Known-Bad-States y runbooks como mínimo.
Conclusión: la planificación de sucesión es seguridad operativa – medible, auditable, planificable
La planificación de sucesión para roles críticos de TI no solo reduce el riesgo de que personas individuales sean „insustituibles“. Hace que la operación sea más resiliente: los accesos están controlados, el conocimiento está documentado y es manejable, las decisiones están respaldadas por roles y gobernanza, y las rutas de emergencia están ensayadas. Para la dirección de TI y la dirección ejecutiva el tema pasa a ser controlable: los riesgos están priorizados, las medidas tienen plazos, y el efecto puede verificarse mediante ejercicios, protocolos de revisión y métricas de incidentes.
Si busca cómo empezar, comience con los servicios principales, haga que los accesos privilegiados sean gestionables por el equipo y ensaye las rutas de RESTauración y de escalamiento. Eso proporciona rápidamente la mayor reducción de riesgo y una base sólida para la preparación para auditorías y la continuidad en el día a día.
Para este tema también son importantes la continuidad de TI y la Business Continuity IT. El artículo ordena estos aspectos de forma comprensible y muestra en qué hay que centrarse en el día a día.