Devolver el computador y retirar una tarjeta no cierra todos los accesos de una persona. Una sesión en el navegador, una aplicación contratada por un área o una integración registrada a su nombre pueden seguir funcionando después de su salida. Para una empresa peruana, el cierre requiere coordinar personas, tecnología y propietarios de servicios hasta comprobar qué quedó deshabilitado y qué se transfirió de forma segura.
Esta guía aborda salidas de empleados y contratistas, con atención a servicios en la nube, sesiones y responsabilidades operativas. No supone una conducta maliciosa de quien termina su vínculo. Un proceso de baja bien diseñado protege a ambas partes, mantiene continuidad y reduce la dependencia de recordatorios informales. Tampoco presenta una guía de la plataforma estatal peruana como obligación general para toda empresa privada.
La fecha de salida debe activar un proceso definido
El primer paso es una notificación verificable desde el área que conoce el vínculo. Recursos Humanos, compras o el responsable contractual deben informar identidad, fecha efectiva y responsables de la transición. Tecnología no debería inferir una salida por rumores ni conservar acceso porque no recibió una solicitud completa. El proceso necesita una ruta para cambios de fecha y situaciones urgentes.
La coordinación debe distinguir salidas programadas, terminaciones inmediatas y finalización de contratos externos. El momento de revocar accesos se acuerda con los responsables correspondientes. Una transferencia de archivos puede prepararse antes, pero no justifica mantener indefinidamente una cuenta personal activa. Las excepciones requieren alcance, responsable, vencimiento y una comprobación posterior.
También debe existir una identificación inequívoca de la persona. Nombres similares, cuentas duplicadas o usuarios externos pueden causar errores. El expediente de baja necesita relacionar los identificadores técnicos con el vínculo correcto. Revocar una cuenta equivocada interrumpe el negocio; omitir una cuenta secundaria deja incompleto el cierre. Ambas situaciones se previenen con datos y responsables claros.
Saber qué tiene la persona y qué depende de ella
El directorio corporativo es un punto de partida, no necesariamente el inventario completo. Puede haber aplicaciones con identidad local, servicios de un proveedor, accesos invitados y cuentas creadas directamente por un área. La revisión debe combinar registros de identidad con información de responsables de negocio, contratos y herramientas de administración disponibles.
Las guías oficiales de usuarios y accesos de Gob.pe señalan prácticas como cuentas individuales y un proceso formal de baja para su plataforma. Su ámbito es específico, pero ilustra un principio operativo útil: una cuenta asociada a una persona facilita asignar responsabilidades y retirar permisos. Las cuentas compartidas dificultan saber qué debe revocarse y quién conserva credenciales.
Además de permisos, hay que identificar propiedad. Una persona puede ser propietaria de un flujo automatizado, de un repositorio, de un panel o de la facturación de una aplicación. Cerrar su cuenta sin revisar esas dependencias puede detener procesos. La solución consiste en transferir responsabilidades a una identidad apropiada y a un propietario activo, con permisos mínimos y evidencia de funcionamiento.
| Área de revisión | Acción de cierre o transferencia | Evidencia esperada |
|---|---|---|
| Identidad principal | Bloquear acceso y retirar permisos según el plan | Confirmación administrativa y prueba autorizada |
| Aplicaciones independientes | Deshabilitar usuario o retirar asignación | Respuesta del propietario del servicio |
| Sesiones y dispositivos | Revocar sesiones y tratar equipos administrados | Registro de acciones y limitaciones |
| Automatizaciones | Transferir propiedad y revisar credenciales | Ejecución validada con nuevo responsable |
| Archivos y correo | Preservar y transferir según política aplicable | Destinatario autorizado y retención definida |
El inventario debe incluir lo pendiente. Si una aplicación no tiene administrador conocido, esa ausencia merece una tarea con prioridad. Declarar la baja completa porque se ejecutó el directorio central oculta el problema. El cierre puede informar un estado parcial con acciones compensatorias y responsable, hasta obtener evidencia de los servicios restantes.
Deshabilitar una cuenta no siempre termina cada sesión
Microsoft documenta que la revocación de acceso depende de tokens, sesiones y del comportamiento de cada aplicación. Algunas capacidades permiten aplicar cambios con rapidez en servicios compatibles; otras sesiones pueden persistir hasta que el servicio vuelva a comprobar su validez o termine su duración. No se debe prometer una revocación instantánea y universal desde un único botón.
Por eso, el procedimiento debe distinguir bloquear nuevos inicios, revocar sesiones, retirar permisos y deshabilitar accesos propios de aplicaciones. Estas acciones se relacionan, pero no son idénticas. El equipo necesita conocer qué cubre su plataforma de identidad y qué requiere intervención adicional del propietario de un servicio o del proveedor.
Los usuarios externos añaden otro límite. Una cuenta invitada puede autenticarse en una organización diferente y recibir permisos en la propia. Retirar la relación o los permisos locales no equivale a administrar la identidad de origen. El cierre debe enfocarse en los recursos que la empresa controla y coordinar lo que corresponde al proveedor, sin asumir facultades sobre otro directorio.
Las pruebas deben ser autorizadas y respetar la privacidad. No es necesario solicitar la contraseña personal de quien sale ni entrar a sus servicios particulares. Se puede comprobar el estado administrativo, utilizar sesiones de prueba bajo un procedimiento acordado y revisar registros. Si una aplicación no permite verificar suficientemente el cierre, el equipo debe documentar esa limitación y su respuesta.
Tratar secretos y accesos compartidos con criterio
Si la persona conocía una credencial compartida o administraba un secreto de integración, la salida debe activar una evaluación de rotación. No todas las claves tienen el mismo riesgo ni pueden cambiarse sin preparación. Primero hay que identificar consumidores, propietario y mecanismo de actualización. Después se realiza el cambio con validación para evitar dejar una dependencia operativa sin servicio.
Las claves personales de API, tokens de desarrollo y certificados asociados a la persona necesitan atención explícita. Retirar una cuenta de correo no garantiza que esas credenciales dejen de funcionar en otras plataformas. El equipo debe revisar su emisión, permisos y revocación según cada producto. Una cuenta técnica debe tener propietario vigente y no depender de la permanencia de una persona específica.
El cierre también es una oportunidad para reducir cuentas compartidas. Cuando no es viable eliminarlas inmediatamente, deben existir custodia, uso controlado y procedimiento de rotación. La dificultad para determinar quién conoce una contraseña es un hallazgo de gestión, no una razón para considerar completa la baja. El plan de mejora debe prevenir que la misma incertidumbre reaparezca con la siguiente salida.
Transferir información sin convertir acceso en archivo
Conservar una cuenta activa para que otro empleado consulte documentos mezcla continuidad con identidad. Es preferible transferir información y responsabilidades mediante capacidades administrativas, con destinatario autorizado y plazo. Las reglas de conservación deben considerar contratos, privacidad y necesidades legítimas del negocio. No corresponde copiar indiscriminadamente toda la información a un dispositivo personal o a una cuenta informal.
El correo requiere una decisión específica. Reenvíos, respuestas automáticas y acceso delegado deben evaluarse con los responsables de privacidad y legal según el contexto. El objetivo de continuidad no autoriza cualquier lectura o divulgación. El procedimiento debe indicar qué se conserva, quién puede acceder y cuándo termina la medida, además de comunicar cambios a los contactos que corresponda.
Los procesos automáticos necesitan una prueba funcional después de la transferencia. Cambiar el nombre del propietario en un registro puede no renovar conexiones o permisos internos. Conviene ejecutar una tarea controlada, confirmar destinatarios y revisar errores. La evidencia de continuidad debe acompañar a la de revocación; ninguna de las dos sustituye a la otra.
Un contratista termina y su automatización sigue siendo necesaria
Consideremos una distribuidora en Lima que contrató apoyo para crear reportes de ventas. Este caso es hipotético. Al finalizar el contrato, se retira el acceso al directorio y se devuelve el equipo. Sin embargo, una aplicación de reportes mantiene un usuario local y un flujo está registrado con un token personal. El informe semanal depende de esa configuración.
Un cierre limitado al directorio dejaría acceso residual y una dependencia frágil. El proceso completo identifica la aplicación, retira el usuario local, transfiere el flujo a una identidad apropiada y rota la credencial después de preparar la actualización. La empresa valida el reporte con datos controlados y registra un nuevo propietario. Así conserva la operación sin prolongar el acceso del contratista.
Un Security GAP Assessment puede ayudar a identificar estas brechas entre políticas y ejecución. La evaluación debe seguir casos reales autorizados, revisar evidencia y señalar límites. Una lista genérica de recomendaciones no demuestra que las bajas de una organización hayan quedado completas ni que todos sus servicios estén inventariados.
Un cierre necesita varias confirmaciones
El área del vínculo confirma fecha y condiciones. Identidad ejecuta acciones centrales. Los propietarios de aplicaciones atienden accesos locales y transferencias. Seguridad revisa excepciones y evidencias. El responsable del expediente consolida el resultado. En una organización pequeña una persona puede asumir varias funciones, pero cada decisión debe seguir siendo identificable.
El SGSI permite relacionar este proceso con control de acceso, activos, proveedores y retención de información. Es importante que la baja no viva únicamente en un formulario aislado. Cuando se compra una aplicación, su propietario y su procedimiento de deshabilitación deberían incorporarse al inventario que utilizará el siguiente cierre.
Un CISO as a Service puede coordinar prioridades cuando intervienen varias áreas o proveedores. Esa coordinación debe resolver responsabilidades, plazos y excepciones. No reemplaza la confirmación técnica de cada plataforma ni debe declarar cierre total cuando existen aplicaciones pendientes sin evidencia.
Cómo saber si el proceso está funcionando
La medición puede registrar tiempo desde la fecha efectiva hasta las acciones definidas, aplicaciones pendientes y excepciones vencidas. Conviene separar revocación de transferencia para no ocultar una demora en un promedio general. Un caso con acceso central cerrado y servicio externo pendiente requiere atención aunque el formulario principal figure como completado.
También resulta útil revisar una muestra de bajas y comparar personas, aplicaciones y evidencias. Esa revisión debe tener un alcance autorizado y protección de datos. Si encuentra cuentas residuales, necesita una ruta de corrección inmediata y análisis de causa: inventario incompleto, notificación tardía, propietario ausente o capacidad técnica insuficiente.
La prueba periódica del proceso puede utilizar una identidad de ensayo con accesos representativos. Se simula su salida, se ejecuta el procedimiento y se verifica qué ocurre con sesiones, aplicaciones y automatizaciones. El resultado ayuda a descubrir dependencias antes de una baja urgente. No debe hacerse con una persona real sin coordinación ni con operaciones que puedan afectar servicios esenciales.
Un cierre mínimo que pueda sostenerse
Seleccione primero el inventario de aplicaciones relevantes y confirme propietarios. Defina quién notifica, qué datos entrega y quién consolida evidencia. Documente acciones centrales y las que requieren intervención local. Prepare transferencia de procesos, rotación de secretos y reglas de conservación. Deje una ruta para urgencias y una forma de registrar excepciones con vencimiento.
Después revise un caso reciente autorizado y un ensayo controlado. Ajuste los puntos que dependieron de memoria o mensajes informales. La mejora más valiosa puede ser sencilla: asignar propietario a una aplicación olvidada o incorporar a compras al aviso de salida de contratistas. La madurez se observa en cierres verificables y sostenidos, no en la extensión del formulario.
Preguntas frecuentes
¿Cambiar la contraseña basta para cerrar todos los accesos?
No necesariamente. Pueden existir sesiones, tokens, aplicaciones independientes y credenciales de integración. El procedimiento debe identificar qué cubre cada acción y comprobar los servicios relevantes, con atención a las limitaciones documentadas por los proveedores.
¿Podemos mantener la cuenta activa para conservar los archivos?
La continuidad debe resolverse mediante retención y transferencia autorizadas, según las capacidades del producto y la política aplicable. Mantener una identidad personal activa indefinidamente dificulta el cierre y puede conservar permisos innecesarios.
¿La guía de Gob.pe obliga a toda empresa privada peruana?
La referencia utilizada describe prácticas de usuarios y accesos de esa plataforma. No debe presentarse como obligación general para empresas privadas. Las obligaciones concretas necesitan análisis según actividad, contratos y normativa aplicable.
Documentación oficial consultada
Consulte las prácticas de usuarios y accesos de Gob.pe, la documentación de Microsoft Entra sobre revocación de acceso y el procedimiento de Microsoft 365 para antiguos empleados. Las recomendaciones de esta guía deben adaptarse a los productos y responsabilidades de cada organización.
