Según el Data Breach Investigations Report 2026, de Verizon —el estudio anual que analizó más de 22.000 violaciones de datos confirmadas en 145 países entre octubre de 2024 y noviembre de 2025—, aprovechar vulnerabilidades técnicas ya es la puerta de entrada más común en los ataques. Pero el informe también aísla una categoría aparte, el abuso de privilegio: alguien que usa un acceso que ya tenía dentro de la organización, sin entrar desde afuera. Esa categoría representó el 3% de las violaciones confirmadas en el conjunto de datos de 2026.
El número parece pequeño frente a otros. Pero describe exactamente la situación más común cuando una empresa trata la salida de un empleado como un asunto de RR. HH.: el gafete se devuelve en portería, se firma la carta, y nadie avisa que el acceso al correo, al sistema de ventas, al panel de hospedaje o al grupo de mensajes del equipo sigue en pie. A veces por semanas. A veces por años.
Un vendedor que se fue en marzo y todavía podía abrir la lista de precios con la cuenta antigua en julio no es un caso raro ni un error exótico de configuración. Es el resultado normal de un proceso que nunca existió por escrito: nadie decidió quién avisa, cuándo avisa y qué hay que cortar exactamente. Para quien aprueba el presupuesto y para quien cuida la TI sin mucha experiencia, esa es la pregunta que vale más que cualquier herramienta nueva: si alguien se fuera hoy, ¿quién sabría hacer la lista de todo lo que esa persona todavía alcanza?
Cuentas que nadie recordó cerrar
Microsoft, el fabricante del sistema más usado como registro de usuarios y contraseñas de la empresa, describe el momento de la salida como una fase propia del ciclo de vida de cualquier cuenta dentro de una organización, junto con el ingreso y el cambio de función. Según la documentación oficial del producto, el objetivo de esa fase es fácil de enunciar y difícil de cumplir: garantizar que quien ya no está vinculado a la empresa, por despido, renuncia o jubilación, tenga el acceso revocado a tiempo.
El problema es que "revocar el acceso" nunca es una sola acción. En una empresa pequeña o mediana, la misma persona suele tener cuenta en el registro de usuarios y contraseñas, su propio correo, acceso al sistema de ventas o de gestión, acceso al panel del sitio o del hospedaje, participación en grupos de mensajes con clientes y, con frecuencia, conocimiento de al menos una contraseña que usa todo el equipo. Cada uno de esos sistemas tiene su propio botón de apagado, cuando lo tiene.
Sin una lista previa de qué sistemas alcanza cada función, nadie puede revocar "todo": la frase no tiene ninguna referencia contra la cual comprobarse. Por eso la salida termina siendo, en la práctica, un intento de recordar de memoria, y la memoria es el peor lugar para guardar una lista de accesos críticos.
El caso más difícil dentro de esa lista suele ser la contraseña compartida del equipo: la del perfil de redes sociales de la empresa, la de un sistema de un proveedor, la del router. No pertenece a una sola persona, así que "revocarla" no es dar de baja una cuenta: es cambiar una contraseña que varias personas siguen usando todos los días, y cambiarla siempre incomoda a quien se queda.
La salida tratada como un asunto solo de RR. HH.
La forma común de manejar esto separa dos conversaciones que deberían ser una sola. RR. HH. se encarga de lo suyo: preaviso, liquidación, devolución de gafete y equipo. La TI —cuando hay alguien dedicado a eso— se entera de la salida cuando alguien se acuerda de avisar, a veces días después, a veces solo cuando un cliente o un compañero nota algo raro.
Esa separación tiene sentido en empresas grandes, con sistemas de RR. HH. y de identidad que se comunican entre sí. En una empresa pequeña, sin esa integración, se convierte en un agujero: el proceso formal termina, pero el técnico queda incompleto. La cuenta del registro de usuarios y contraseñas sigue activa porque nadie pidió desactivarla; el acceso remoto al servidor sigue habilitado porque estaba en una lista que solo veía una persona.
Hay además un sesgo que empeora el panorama: las salidas tranquilas reciben menos atención que las conflictivas. Cuando alguien se va en buenos términos, la sensación de urgencia desaparece —"no va a hacer nada malo"— y el corte de acceso queda para después, un después que muchas veces no llega. El riesgo, sin embargo, no depende de la intención de quien se fue: una cuenta activa puede usarla cualquiera que descubra la contraseña, incluso alguien que nunca trabajó ahí.
Lo que tiene que existir en la práctica
Una salida segura se apoya en mecanismos verificables, no en la buena voluntad de quien se acuerda de avisar.
Una lista de accesos por persona, armada el día en que ingresa, no el día en que se va. Cada función tiene un conjunto previsible de sistemas: registro de usuarios y contraseñas, correo, sistema de ventas, hospedaje, grupos de mensajes. Registrar esto al contratar es lo que permite revisar todo en la salida, en vez de intentar reconstruirlo de memoria.
Un aviso de salida que llega al mismo tiempo a RR. HH. y a quien cuida la TI. El disparador es un solo evento, comunicado en ambos sentidos en el mismo momento, no un correo de RR. HH. que alguien reenviará "cuando pueda".
Revocación sistema por sistema, con lista de verificación, no un botón único. No existe un interruptor que apague todo de una vez en una estructura con varios proveedores. Lo que existe es una lista corta y específica, revisada un elemento a la vez, hasta cerrarla.
Contraseña de equipo cambiada el mismo día, no solo tachada de una lista. Si la persona que se fue conocía un acceso colectivo, la única forma de cerrar ese acceso es generar una contraseña nueva y entregarla a quien todavía la necesita, avisando antes para no dejar a nadie bloqueado en medio del trabajo.
Un segundo paso de confirmación además de la contraseña en los sistemas más críticos. No reemplaza la revocación, pero reduce el daño si una contraseña vieja se filtra por algún motivo, porque exige una segunda confirmación que la cuenta dada de baja ya no puede dar.
Revisión periódica de quién todavía tiene acceso a cada sistema, no solo cuando alguien se va, para detectar lo que quedó pendiente de salidas anteriores antes de que se convierta en un hallazgo incómodo en una auditoría.
Así es como trabaja la Skills IT: el aviso de salida entra como un único ticket para el equipo de soporte, la revocación sigue una lista de verificación por sistema, y la contraseña de equipo compartida se cambia el mismo día, nunca solo se tacha de una lista que nadie vuelve a revisar.
Lo que gana la empresa cuando la salida se vuelve proceso
La ganancia más inmediata es la más fácil de explicar: una lista de precios, una base de clientes o un contrato no circula por la cuenta de alguien que ya no responde por nada en la empresa. Eso vale tanto para quien se fue en buenos términos como para quien se fue en conflicto, y es justamente en el segundo caso donde el proceso importa más, porque ahí es donde la buena voluntad de "no va a hacer nada" deja de servir como garantía.
También hay una ganancia de tiempo para quien cuida la TI. Sin una lista previa, cada salida se convierte en una investigación: averiguar en qué sistemas tenía cuenta la persona, esperar no olvidar ninguno, confirmar después si quedó algo pendiente. Con una lista de verificación lista, la misma salida se convierte en una revisión de diez minutos.
Y hay una ganancia en auditoría. La propia documentación de gobernanza de identidad de Microsoft señala que el exceso de acceso sin usar es, por sí solo, motivo de observación en auditorías, señal de falta de control sobre quién tiene acceso a qué, sin importar si ocurrió algún incidente. Una empresa que revisa esto periódicamente llega a esas conversaciones con la respuesta lista, en vez de descubrir el problema junto con el auditor.
Nada de esto depende de creer que los exempleados actúan de mala fe. Depende de tratar el acceso como algo que necesita un responsable y un plazo, porque una cuenta olvidada es un riesgo incluso cuando nadie la usa para nada.
Una guía para la próxima salida
Antes de que ocurra la próxima salida, amistosa o no, vale la pena tener esto acordado entre la dirección, RR. HH. y quien cuida la TI:
- Pida la lista antes de avisar la salida. Antes de comunicar la salida, levante qué accede esa persona: correo, sistema de ventas, hospedaje, grupos de mensajes, cualquier contraseña de equipo que conozca.
- Acuerde la hora del corte, no solo el día. Definir "hoy" sin definir "a las 17 h" deja una ventana abierta, casi siempre el fin de semana o la noche, en la que la cuenta sigue activa y nadie está mirando.
- Cambie, no solo elimine, la contraseña compartida. Si el equipo usa un acceso colectivo, este es el momento de generar una contraseña nueva y avisar a quien todavía la necesita, en vez de esperar que la persona que se fue no la use más.
- Confirme sistema por sistema, uno a la vez. Correo, registro de usuarios y contraseñas, sistema de ventas, panel del proveedor, acceso remoto. Si esa lista todavía no existe, esta salida es el momento de empezar a escribirla.
- Aproveche para preguntar quién más tenía ese mismo acceso. Es común que una salida revele una cuenta genérica o una contraseña compartida que ya nadie recuerda por qué sigue existiendo: vale la pena revisarla mientras el tema está sobre la mesa.
