Cuando una base de datos desaparece justo antes de la salida de un empleado, la coincidencia es una señal para investigar, no una prueba automática de autoría. Puede existir una eliminación intencional, un proceso programado, un error de mantenimiento, un fallo de almacenamiento o un ataque externo.
Antes de restaurar, determina si fueron tablas, registros, archivos, respaldos o toda la instancia. Contén escrituras y preserva logs, transacciones, auditoría, eventos del sistema y accesos remotos. Restaurar una copia puede devolver la operación y, al mismo tiempo, cambiar la evidencia que explicaría el mecanismo.
Que una base deje de mostrar información no demuestra que alguien la haya borrado. Puede existir un archivado automático, una ruta cambiada, un permiso insuficiente o una falla de almacenamiento. La investigación debe comenzar por determinar si los datos siguen físicamente disponibles y qué evento explica su desaparición en la aplicación, antes de atribuir una conducta al empleado que acaba de salir.
Después se revisan registros de transacciones, consultas destructivas, respaldos, cambios de configuración y dispositivos de origen. Incluso si aparece una instrucción de borrado ejecutada con su usuario, la autoría necesita otra capa: la cuenta puede estar compartida o comprometida y debe relacionarse con sesión, equipo y acceso físico.
Preserva servidores y copias antes de restaurar, y no ejecutes consultas destructivas en producción para comprobar una teoría. Dirección y Jurídico delimitan la investigación; el peritaje documenta qué ocurrió y qué puede recuperarse. La ausencia en pantalla, el evento de eliminación y la persona responsable son tres preguntas diferentes. Contestarlas en orden evita tanto una acusación falsa como una restauración que borre la evidencia del verdadero incidente.
La autoría es otra pregunta: la cuenta del empleado puede estar compartida o comprometida y hay que relacionar dispositivo, origen de conexión y credenciales. No confrontes antes de preservar ni ejecutes consultas destructivas en producción para comprobar tu teoría. El análisis debe distinguir qué ocurrió, quién pudo hacerlo y qué sigue sin demostrarse.
Lo primero es preservar los sistemas y los registros. Si restauras una copia sin documentar nada, puedes recuperar la operación y perder la explicación técnica del incidente.
Contén el daño sin borrar los rastros
Suspende procesos que puedan sobrescribir información, limita escrituras en los volúmenes afectados y aísla los componentes comprometidos cuando sea necesario. No reinicies repetidamente ni ejecutes limpiezas. Cada acción debe quedar anotada con fecha, responsable y motivo.
Identifica qué se perdió: tablas, registros, archivos, respaldos, credenciales o toda la instancia. No uses la palabra borrado como conclusión si todavía no sabes si los datos fueron eliminados, movidos, cifrados o simplemente dejaron de ser accesibles.
Si la empresa necesita volver a operar, preserva primero imágenes, registros y copias relevantes, o trabaja sobre medios separados. La continuidad y la investigación deben coordinarse, no competir.
Qué registros pueden ayudar
Dependiendo de la tecnología, pueden existir bitácoras del motor, registros de transacciones, auditoría de accesos, eventos del sistema operativo, tablas del sistema, registros de aplicaciones, consolas de administración y copias de seguridad. En discos pueden ser relevantes estructuras como la MFT y otros artefactos del sistema de archivos.
Conserva también accesos de usuarios, sesiones remotas, tareas programadas, tickets de mantenimiento y alertas. La consulta que elimina datos puede dejar una huella distinta al borrado de archivos físicos. Por eso el análisis debe adaptarse al sistema real, no a una receta genérica.
Documenta la zona horaria y sincronización de cada servidor. Una diferencia de minutos entre registros puede cambiar toda la secuencia si no se corrige técnicamente.
De la eliminación a la autoría
Demostrar que hubo una eliminación es una pregunta; demostrar quién la ejecutó es otra. Una cuenta asignada al empleado puede haber sido utilizada por otra persona, compartida o comprometida. Deben revisarse dispositivo, origen de conexión, credenciales, horario, controles y demás eventos relacionados.
Compara sus funciones y permisos con lo ocurrido. Que alguien tuviera acceso demuestra capacidad, no ejecución. Las conversaciones, la entrega de equipo y las acciones posteriores pueden aportar contexto, pero no sustituyen los registros técnicos.
Evita confrontar al sospechoso antes de preservar. Una llamada emocional puede provocar borrado de mensajes, cierre de sesiones o alteración de respaldos. Tampoco accedas a cuentas personales ajenas para buscar una confesión.
Recuperación y cadena de custodia
Las copias de seguridad, réplicas, registros de transacciones o versiones anteriores pueden permitir restauración parcial o total. Verifica su integridad y documenta cualquier recuperación. No prometas que todos los datos volverán: depende de la tecnología, la retención y el tiempo transcurrido.
Calcula huellas de integridad de los archivos preservados y registra quién los custodia, dónde se almacenan y quién accede a ellos. Las copias de trabajo deben separarse de los originales.
El informe debe distinguir hechos observados, indicios y conclusiones. Si no puede atribuirse la acción, decirlo es parte de un análisis honesto. Un dictamen no mejora por acusar más, sino por explicar mejor.
Prevención posterior
Aplica privilegios mínimos, cuentas individuales, doble factor, respaldos inmutables o separados y alertas para operaciones destructivas. Revisa los accesos durante el proceso de salida sin esperar al último día.
Realiza pruebas reales de restauración. Un respaldo que nunca se ha probado es una esperanza con espacio en disco.
La eliminación y la autoría son dos preguntas técnicas distintas
Una base de datos borrada por empleado o eliminación de registros antes de la baja puede analizarse con transacciones, auditoría, eventos del sistema, MFT y respaldos, según tecnología. La cuenta registrada no identifica por sí sola a la persona física. La empresa necesita contener escrituras y preservar antes de restaurar; el abogado necesita dispositivo, origen de conexión y custodia de credenciales. No se confronta antes de asegurar registros ni se publican consultas destructivas para replicar el evento.