Peritaje de fichaje: cómo un perito detecta manipulaciones

En el 34 % de las inspecciones de trabajo realizadas en España durante 2024, la Inspección de Trabajo y Seguridad Social (ITSS) detectó anomalías en los registros de jornada. No hablamos de errores menores: registros que aparecen y desaparecen, fichajes creados retroactivamente en bloque, o jornadas de 12 horas que misteriosamente figuran como 8 en el sistema. Pero ¿cómo distingue un tribunal un registro legítimo de uno manipulado? ¿Qué busca exactamente un perito informático forense cuando analiza una base de datos de fichajes? La respuesta está en la pericia informática forense, y en este artículo voy a explicarte, paso a paso, cada técnica que utilizo para detectar manipulaciones en sistemas de registro de jornada.

Tras más de una década como perito informático forense, he analizado sistemas de fichaje de todo tipo: desde hojas de cálculo Excel hasta aplicaciones móviles con geolocalización, pasando por sistemas biométricos y plataformas con integridad criptográfica. En cada caso, la pregunta fundamental es la misma: ¿se puede demostrar que los datos no han sido alterados? Y la respuesta depende de la arquitectura técnica del sistema, de sus logs de auditoría y, sobre todo, de la presencia o ausencia de mecanismos criptográficos de integridad.

Este artículo es la guía más completa que encontrarás en español sobre peritaje informático de registros de fichaje. Cubre desde los fundamentos jurídicos (qué dice el Tribunal Supremo y el TJUE) hasta las técnicas forenses más avanzadas (hash criptográfico, análisis de metadatos, correlación con múltiples fuentes), pasando por la jurisprudencia real aplicable, las herramientas que utilizo como perito y los requisitos que debe cumplir un sistema de fichaje para ser admisible como prueba digital en juicio. Si eres abogado laboralista, responsable de RRHH, trabajador en disputa con tu empresa o simplemente quieres entender cómo funciona la pericia informática en el ámbito laboral, aquí encontrarás las respuestas.

TL;DR — Lo que un perito busca en tu fichaje

Sin integridad forense verificable, el registro de fichaje pierde su valor como prueba digital en un procedimiento judicial. Y esto no es una opinión: es lo que establece la doctrina del Tribunal Supremo desde la sentencia STS 1161/2024.

1. El registro de jornada como prueba digital

El registro de jornada dejó de ser una mera formalidad administrativa el 12 de mayo de 2019, cuando entró en vigor el Real Decreto-ley 8/2019. Desde entonces, toda empresa está obligada a registrar la jornada diaria de cada trabajador, incluyendo hora de inicio y finalización. Pero lo que muchos ignoran es que ese registro, en el momento en que se aporta a un procedimiento judicial, se convierte en una prueba digital sujeta a requisitos de admisibilidad específicos.

1.1 Naturaleza jurídica del registro de fichaje

El registro de jornada tiene una naturaleza dual que genera confusión tanto en empresas como en trabajadores:

Como obligación administrativa, el artículo 34.9 del Estatuto de los Trabajadores exige que la empresa garantice «el registro diario de jornada, que deberá incluir el horario concreto de inicio y finalización de la jornada de trabajo de cada persona trabajadora». El incumplimiento puede conllevar sanciones de 751 a 7.500 euros por infracción grave (artículo 7.5 de la LISOS).

Como prueba digital, cuando ese registro se presenta ante un juzgado de lo social, entra en juego el artículo 382 de la Ley de Enjuiciamiento Civil, que regula la prueba por instrumentos electrónicos. Ya no basta con presentar un listado: hay que demostrar que los datos son auténticos, íntegros y no han sido manipulados.

Esta dualidad explica por qué un sistema de fichaje que cumple con la obligación legal puede, sin embargo, ser inútil como prueba en un juicio. Cumplir la ley y generar evidencia forense no son lo mismo.

1.2 Requisitos de admisibilidad en juzgados de lo social

Para que un registro de fichaje sea admitido como prueba en un procedimiento laboral, debe cumplir cuatro requisitos fundamentales:

1. Autenticidad: Debe poder demostrarse que los datos provienen efectivamente del sistema de fichaje de la empresa y no han sido fabricados.
2. Integridad: Los datos no deben haber sido alterados desde su generación. Aquí es donde el hash criptográfico se convierte en pieza clave.
3. Fiabilidad del sistema: El sistema que generó los datos debe ser técnicamente fiable. Un Excel compartido en red no cumple este requisito.
4. Cadena de custodia: Debe documentarse quién ha tenido acceso a los datos, cuándo y con qué finalidad, desde su generación hasta su presentación en juicio.

Cuando alguno de estos requisitos falla, la contraparte puede impugnar la prueba. Y si no hay un informe pericial que respalde la integridad del sistema, el juez tiene motivos de sobra para desestimar el registro como prueba.

1.3 La doctrina del Tribunal Supremo: «objetivo, fiable y accesible»

La Sentencia del Tribunal Supremo 1161/2024, de 24 de septiembre, estableció un estándar claro para los sistemas de registro de jornada. El TS exige que el sistema sea:

• Objetivo: No puede depender de la voluntad unilateral de una de las partes. Un sistema donde el administrador puede modificar registros sin dejar rastro no es objetivo.
• Fiable: Debe ofrecer garantías técnicas de que los datos registrados reflejan la realidad. La fiabilidad se mide en términos de integridad de datos, trazabilidad de modificaciones y resistencia a la manipulación.
• Accesible: El trabajador debe poder consultar sus registros. Un sistema al que solo accede la empresa incumple este requisito.

Esta sentencia ha marcado un antes y un después en los peritajes de fichaje. Antes de ella, muchos jueces aceptaban cualquier listado impreso como prueba suficiente. Ahora, la exigencia de fiabilidad técnica abre la puerta a que un perito informático evalúe la robustez del sistema.

Además, la STS 410/2024, de 5 de marzo, reforzó que el registro de jornada no puede ser utilizado por la empresa para modificar unilateralmente las condiciones laborales. Es decir, el registro documenta la realidad, no la crea.

1.4 STJUE Deutsche Bank (C-55/18) y su impacto en España

El 14 de mayo de 2019, el Tribunal de Justicia de la Unión Europea dictó la sentencia que catalizó la normativa española. En el asunto C-55/18 (Federación de Servicios de Comisiones Obreras contra Deutsche Bank SAE), el TJUE estableció que:

«Los Estados miembros deben imponer a los empresarios la obligación de implantar un sistema objetivo, fiable y accesible que permita computar la jornada laboral diaria realizada por cada trabajador.»

La clave está en la palabra «sistema»: no basta con anotar las horas. Debe existir un sistema técnico con garantías. El TJUE no especificó qué tipo de sistema (dejando margen a cada Estado), pero los tres adjetivos —objetivo, fiable, accesible— se han convertido en el test jurídico que aplican los tribunales españoles.

Desde la perspectiva forense, estos tres adjetivos se traducen en requisitos técnicos concretos:

1.5 Cronología legal del registro de jornada en España

Para situar el contexto, es útil repasar la evolución normativa y jurisprudencial:

Esta cronología muestra una tendencia clara hacia la exigencia de mayor rigor técnico en los sistemas de registro. Lo que era aceptable en 2019 (un Excel compartido) ya no lo es en 2026 a la luz de la jurisprudencia más reciente.

1.6 Diferencia entre registro obligatorio y prueba digital

Es fundamental entender que cumplir con la obligación de registrar la jornada no equivale a disponer de una prueba digital válida. Son dos planos distintos:

El registro obligatorio (artículo 34.9 ET) solo exige que exista un registro con hora de inicio y fin. No dice nada sobre hashes, logs de auditoría ni cadena de custodia. Una empresa puede cumplir perfectamente con esta obligación usando una hoja de cálculo compartida en Google Drive.

La prueba digital (artículo 382 LEC) exige autenticidad, integridad, fiabilidad y cadena de custodia. La hoja de cálculo anterior, si se impugna, difícilmente superará un análisis pericial porque carece de trazabilidad y cualquier usuario con acceso puede modificarla sin dejar rastro.

La consecuencia práctica es directa: una empresa puede estar cumpliendo la ley y, al mismo tiempo, ser incapaz de defender sus registros ante un tribunal. Y un trabajador puede tener razón sobre sus horas extras pero carecer de evidencia digital sólida para demostrarlo.

2. Tipos de sistemas de fichaje y sus vulnerabilidades

No todos los sistemas de fichaje ofrecen las mismas garantías. Desde el punto de vista forense, la pregunta clave es: ¿qué tan fácil es manipular los datos sin dejar rastro? La respuesta varía enormemente según la tecnología empleada.

2.1 Registro en papel: manipulación trivial

El registro en papel sigue siendo más común de lo que cabría esperar. Según datos de la ITSS, aproximadamente un 15 % de las empresas inspeccionadas en 2024 seguían utilizando registros manuales en papel.

Desde la perspectiva forense, el papel presenta vulnerabilidades insalvables:

• Sin trazabilidad: No hay forma de saber cuándo se escribió realmente cada anotación. Un registro «completado» retroactivamente la noche antes de una inspección es indistinguible de uno rellenado día a día.
• Sin integridad: Cualquiera puede tachar, sobrescribir o añadir anotaciones.
• Sin control de acceso: No hay logs de quién accedió al registro ni cuándo.
• Análisis pericial limitado: Un perito calígrafo puede analizar la tinta y la presión del trazo, pero las técnicas forenses digitales no son aplicables.

El único escenario donde un registro en papel tiene peso probatorio es cuando ambas partes —empresa y trabajador— firman cada registro diariamente. Aun así, la manipulación retroactiva con firmas falsificadas sigue siendo posible.

2.2 Excel y hojas de cálculo: sin trazabilidad real

Las hojas de cálculo (Excel, Google Sheets, LibreOffice Calc) son probablemente el sistema más utilizado en pymes españolas. Y también uno de los más vulnerables.

Vulnerabilidades críticas del Excel como sistema de fichaje:

• Modificación sin rastro: Cualquier usuario con acceso al archivo puede modificar cualquier celda. Excel no genera logs de auditoría por defecto.
• Metadatos manipulables: La fecha de «última modificación» del archivo cambia con cada edición, pero no identifica qué celdas se modificaron ni quién lo hizo.
• Versiones sobrescribibles: Aunque Office 365 y Google Sheets ofrecen historial de versiones, este historial puede desactivarse o purgarse por el administrador.
• Sin hash de integridad: No existe un mecanismo nativo para verificar que los datos no han sido alterados.

Lo que un perito puede detectar en un Excel:

A pesar de sus limitaciones, un análisis forense de un archivo Excel puede revelar información valiosa:

1. Metadatos del archivo: Fecha de creación real (que puede no coincidir con la supuesta fecha del primer registro), autor original, número de revisiones.
2. Celdas con formato inconsistente: Si se añadieron registros retroactivamente, el formato de las celdas puede diferir (fuente, tamaño, color de fondo).
3. Fórmulas ocultas: Algunas empresas usan fórmulas para calcular automáticamente la jornada, lo que puede revelar manipulaciones si los valores calculados no coinciden con los mostrados.
4. XML interno: Los archivos .xlsx son realmente archivos ZIP que contienen XML. El análisis del XML interno puede revelar timestamps de modificación por hoja o incluso por celda en algunos casos.

Caso especial: Google Sheets como sistema de fichaje

Google Sheets tiene una particularidad que lo hace algo más analizable que Excel local: el historial de versiones automático. Google almacena automáticamente un historial de todos los cambios realizados en la hoja, identificando qué usuario realizó cada cambio, en qué celda y en qué momento.

Sin embargo, este historial tiene limitaciones forenses:

• El propietario del documento puede descargar una copia y eliminar el original (el historial se pierde con el original).
• El historial de versiones detallado solo se conserva durante un periodo limitado (Google no publica la duración exacta, pero en la práctica se observan retenciones de entre 6 meses y varios años dependiendo del plan).
• En cuentas Google Workspace empresariales, el administrador puede acceder al historial de actividad de la organización a través de la consola de administración, lo que proporciona una capa adicional de trazabilidad.

Recomendación: Si una empresa insiste en usar Google Sheets para el registro de jornada (algo que desaconsejo), debe al mínimo: (a) utilizar una cuenta Google Workspace (no Gmail personal), (b) restringir los permisos de edición al mínimo necesario, (c) activar la auditoría de datos en la consola de administración, y (d) realizar exportaciones PDF periódicas firmadas con hash como respaldo.

Lo que NO puede detectar un perito en un Excel:

Es igual de importante documentar las limitaciones:

• Cambios realizados antes de la primera copia: Si la empresa creó un Excel, lo modificó internamente y solo después lo compartió con el trabajador, las modificaciones previas a la compartición pueden ser irrecuperables.
• Modificaciones con la misma cuenta de usuario: Si múltiples personas comparten la misma cuenta (algo frecuente en pymes), el análisis de metadatos no distingue quién realizó cada cambio.
• Archivos reimportados: Si la empresa exportó los datos a CSV, los modificó y los reimportó a un nuevo archivo Excel, los metadatos del archivo nuevo no reflejarán las modificaciones realizadas en el CSV.

2.3 Sistemas de fichaje por PIN o tarjeta: buddy punching

Los sistemas basados en código PIN o tarjeta de proximidad (RFID, NFC) representan un avance respecto al papel y Excel, pero introducen sus propias vulnerabilidades.

La vulnerabilidad principal: buddy punching. El término «buddy punching» (fichar por un compañero) es la manipulación más extendida en sistemas de PIN y tarjeta. Un trabajador comparte su PIN o presta su tarjeta a un compañero para que fiche por él. Según estudios del sector de recursos humanos, el buddy punching puede representar entre un 2 % y un 5 % de los fichajes en empresas sin controles adicionales.

Desde el punto de vista del perito:

• Logs del sistema: Los sistemas de fichaje por tarjeta suelen generar logs básicos (número de tarjeta, hora, terminal). Estos logs permiten análisis de patrones (por ejemplo, un trabajador que siempre ficha en el mismo terminal con diferencia de segundos respecto a otro).
• Acceso de administrador: El administrador del sistema puede, en muchos casos, añadir, modificar o eliminar registros. Si el sistema no genera logs de estas operaciones administrativas, la manipulación por parte de la empresa es indetectable.
• Base de datos: Dependiendo del fabricante, la base de datos puede ser SQLite local, SQL Server o un servicio en la nube. El acceso forense a esta base es fundamental.

2.4 Apps móviles de fichaje: spoofing de ubicación y hora

Las aplicaciones móviles de fichaje se han popularizado enormemente desde la pandemia, especialmente para trabajadores en remoto o itinerantes. Ofrecen ventajas evidentes (geolocalización, fotografía, fichaje desde cualquier lugar), pero también vulnerabilidades específicas.

Vulnerabilidades del lado del empleado:

• GPS spoofing: Existen aplicaciones que permiten falsificar la ubicación GPS del dispositivo. Un trabajador puede simular estar en la oficina mientras se encuentra en su domicilio.
• Manipulación de hora: En dispositivos Android rooteados o iOS con jailbreak, es posible alterar la hora del sistema antes de fichar.
• Dispositivos virtuales: Con emuladores como BlueStacks o Genymotion, se puede ejecutar la app de fichaje en un PC simulando la ubicación deseada.

Vulnerabilidades del lado de la empresa (administrador):

• Panel de administración: La mayoría de apps de fichaje ofrecen un panel web donde el administrador puede editar registros. Si estas ediciones no quedan registradas en un log inmutable, la manipulación es invisible.
• Acceso a la base de datos: En soluciones self-hosted, la empresa tiene acceso directo a la base de datos y puede modificar registros sin pasar por la interfaz de la aplicación.
• API sin autenticación: Algunos sistemas baratos exponen APIs que permiten crear o modificar fichajes directamente, sin que la aplicación móvil intervenga.

Lo que el perito analiza:

Cuando analizo una app de fichaje, me centro en cuatro aspectos:

1. Registro del servidor vs registro del dispositivo: ¿La hora la genera el servidor o el dispositivo del usuario? Si la genera el dispositivo, es falsificable.
2. Geolocalización verificable: ¿Se almacena la precisión del GPS? Una precisión de 5 metros es real; una de 0 metros es sospechosa (ubicación fija/simulada).
3. Integridad de las comunicaciones: ¿La app usa HTTPS con certificate pinning? Sin ello, un intermediario puede interceptar y modificar las peticiones.
4. Logs de la API: ¿El servidor registra todas las peticiones recibidas, incluyendo las que vienen del panel de administración?

Análisis forense específico de apps móviles:

Cuando el peritaje involucra una app de fichaje móvil, el análisis se extiende al propio dispositivo del trabajador (si está disponible) y a la infraestructura del servidor:

En el dispositivo del trabajador (Android):

• Base de datos SQLite local: Muchas apps almacenan una copia local de los fichajes en una base de datos SQLite dentro del directorio de la aplicación (/data/data/com.app.fichaje/databases/). Esta base puede contener registros que fueron modificados o eliminados en el servidor.
• SharedPreferences: Archivo XML que almacena configuración de la app, incluyendo tokens de autenticación, última sincronización y, en algunos casos, el último fichaje registrado.
• Logs del sistema: logcat registra las operaciones de red de la app, incluyendo peticiones HTTP/HTTPS al servidor.
• Cache de la app: Puede contener respuestas del servidor que revelan el estado de los datos en un momento anterior.

En el dispositivo del trabajador (iOS):

• Core Data / SQLite: Similar a Android, los datos locales se almacenan en una base de datos.
• Backups de iTunes/Finder: Si el trabajador tiene backups del dispositivo, se pueden extraer los datos de la app en su estado histórico.
• iCloud: Si la app sincroniza con iCloud, puede haber copias de los datos en la nube de Apple.

En el servidor:

• Logs de acceso del servidor web (nginx/Apache): Registran cada petición HTTP, incluyendo la URL, el método (GET/POST/PUT/DELETE), la IP de origen, el User Agent y el código de respuesta. Una petición PUT o DELETE a la API de fichajes desde el panel de administración deja rastro aquí.
• Logs de la base de datos: El general_log de MySQL o el log_statement de PostgreSQL registran todas las consultas SQL ejecutadas.
• Logs de la aplicación: Los frameworks web modernos (Django, Rails, Laravel, Express) generan sus propios logs de aplicación que pueden registrar operaciones de negocio.

2.5 Sistemas biométricos: irreversibilidad y RGPD

Los sistemas de fichaje biométrico (huella dactilar, reconocimiento facial, iris) ofrecen la ventaja de vincular inequívocamente el fichaje con la persona. El buddy punching es técnicamente imposible.

Sin embargo, presentan desafíos propios:

• RGPD y datos biométricos: Desde la sentencia del TJUE de 2023 (asunto C-205/21) y las resoluciones de la AEPD, los datos biométricos se consideran de categoría especial (artículo 9 RGPD). Su tratamiento requiere consentimiento explícito o un interés legítimo claramente documentado. Varias empresas han sido sancionadas por implementar fichaje biométrico sin la base jurídica adecuada.
• Irreversibilidad: A diferencia de un PIN o una tarjeta, una huella dactilar no se puede cambiar si se compromete la seguridad del sistema.
• Falsos positivos y negativos: La tasa de error de los sistemas biométricos (FRR y FAR) introduce un margen de incertidumbre que puede ser relevante en un procedimiento judicial.

Desde la perspectiva forense, la cuestión clave con los sistemas biométricos es si el registro del fichaje almacena el template biométrico completo o solo un hash del mismo. En el primer caso, hay riesgo de datos personales sensibles expuestos; en el segundo, la verificación pericial es más compleja pero la privacidad está mejor protegida.

2.6 Sistemas con integridad criptográfica: el estándar forense

Los sistemas que implementan verificación de integridad criptográfica representan el estado del arte en fichaje con garantías forenses. Su principio es simple pero potente: cada registro de fichaje se firma digitalmente en el momento de su creación, de modo que cualquier modificación posterior sea detectable.

Cómo funciona:

1. El trabajador realiza su fichaje (entrada o salida).
2. El sistema captura los datos del fichaje: hora, identificador del trabajador, dispositivo, ubicación (si aplica).
3. Se calcula un hash SHA-256 de todos estos datos concatenados.
4. El hash se almacena junto al registro.
5. Opcionalmente, el hash del registro actual se encadena con el hash del registro anterior, creando una cadena de integridad (hash chain).

Resultado: Si alguien modifica cualquier dato del fichaje después de su creación, el hash recalculado no coincidirá con el almacenado. La manipulación se detecta instantáneamente.

Este es el mecanismo que busco como perito cuando analizo un sistema de fichaje en el contexto de una disputa judicial. Si el sistema lo implementa, mi trabajo se simplifica enormemente: recalculo los hashes y verifico si coinciden. Si no lo implementa, debo recurrir a técnicas indirectas (metadatos, análisis estadístico, correlación) que son menos concluyentes.

2.7 Tabla comparativa: vulnerabilidades por tipo de sistema

La conclusión es clara: solo los sistemas con integridad criptográfica ofrecen garantías forenses completas. En todos los demás casos, el perito debe recurrir a técnicas indirectas que, aunque pueden ser efectivas, no ofrecen la certeza binaria de una verificación de hash.

El coste real de elegir el sistema equivocado

Desde mi experiencia como perito, puedo afirmar que la elección del sistema de fichaje es una decisión que tiene consecuencias jurídicas directas. Permíteme ilustrarlo con números:

Escenario A — Empresa con Excel (sin integridad forense):

Un trabajador reclama 3 horas extras diarias durante 18 meses. La empresa presenta su Excel con jornadas de 8 horas. El perito demuestra que el Excel fue creado retroactivamente. El tribunal aplica la presunción pro-trabajador y condena al pago. Resultado:

• Horas extras: 3 horas/día x 220 días/año x 1,5 años = 990 horas
• Coste medio hora extra (con recargo del 75 %): 18 € x 1,75 = 31,50 €
• Total condena: 31.185 € + costas + intereses + sanción ITSS

Escenario B — Empresa con sistema con hash SHA-256:

El mismo trabajador reclama las mismas horas extras. El perito verifica los hashes y confirma que los registros son íntegros: las jornadas efectivas fueron de 8 horas. El tribunal desestima la demanda.

• Coste del sistema de fichaje: 3-6 €/empleado/mes
• Coste evitado: 31.185 € + costas + intereses + sanción

La diferencia entre ambos escenarios no es tecnológica: es financiera y jurídica. Un sistema de fichaje sin garantías forenses es una bomba de relojería para cualquier empresa.

Datos del sector:

Según CC.OO., en 2024 se dejaron de pagar en España más de 3,9 millones de horas extras semanales. La ITSS impuso sanciones por más de 14 millones de euros en materia de tiempo de trabajo. Y las reclamaciones judiciales por horas extras aumentaron un 23 % respecto a 2023.

En este contexto, invertir en un sistema de fichaje con integridad forense no es un lujo: es una medida de gestión de riesgos fundamental.

3. Técnicas forenses de análisis de registros de fichaje

Cuando recibo un encargo de peritaje sobre registros de fichaje, sigo un protocolo sistemático que garantiza la admisibilidad del análisis y sus conclusiones en sede judicial. Las técnicas que describo a continuación constituyen el núcleo de mi metodología forense.

3.1 Adquisición forense de la base de datos

El primer paso, y posiblemente el más crítico, es la adquisición forense de los datos. No se trata de pedir un «export» al departamento de informática: se trata de obtener una copia bit a bit de la base de datos original, garantizando la cadena de custodia desde el primer momento.

Protocolo de adquisición según ISO 27037:

1. Identificación: Localizar el servidor o servicio que aloja la base de datos del sistema de fichaje. En sistemas cloud, identificar el proveedor y la región.
2. Aislamiento: Si es posible, desconectar el sistema de producción para evitar que se modifiquen datos durante la adquisición. En la práctica, esto rara vez es viable sin interrumpir la operativa de la empresa, por lo que se recurre a snapshots o backups consistentes.
3. Adquisición: Realizar una copia forense de la base de datos. Para bases SQL, esto implica un dump completo (estructura + datos + logs de transacciones). Para bases NoSQL, una exportación completa del conjunto de datos.
4. Verificación: Calcular el hash SHA-256 de la copia obtenida y documentarlo en el acta de adquisición.
5. Preservación: Almacenar la copia en un medio de solo lectura (write-once) o en un contenedor cifrado con acceso documentado.

Errores comunes que invalidan la adquisición:

• Solicitar un «informe exportado» desde la interfaz web del sistema (pierde metadatos y logs).
• No documentar la fecha, hora y persona que realizó la adquisición.
• No calcular el hash de la copia inmediatamente después de obtenerla.
• Modificar accidentalmente los datos originales durante la adquisición (por ejemplo, al abrir la base de datos con un editor que modifica timestamps de acceso).

Adquisición en sistemas SaaS (cloud):

Cuando el sistema de fichaje es una aplicación SaaS (Software as a Service), la adquisición presenta desafíos adicionales:

1. Acceso limitado a la base de datos: En un SaaS, la empresa cliente no tiene acceso directo a la base de datos. Solo puede exportar datos a través de la interfaz o la API del proveedor. Esto significa que los metadatos de nivel de base de datos (transaction IDs, WAL, binary logs) no están disponibles.

2. Dependencia del proveedor: En casos judiciales, puede ser necesario requerir al proveedor del SaaS que facilite un dump completo de la base de datos o que certifique la integridad de una exportación. Esto se tramita mediante requerimiento judicial al proveedor.

3. Jurisdicción internacional: Si el proveedor tiene servidores fuera de España (Amazon AWS en Irlanda, Google Cloud en Bélgica, Microsoft Azure en Países Bajos), la cooperación judicial puede implicar comisiones rogatorias o aplicación del RGPD para la transferencia de datos.

4. Retención de datos del proveedor: Muchos proveedores SaaS solo conservan los logs de auditoría durante un periodo limitado (30, 60 o 90 días). Si la solicitud de adquisición llega tarde, los logs pueden haberse eliminado automáticamente.

Mi recomendación: Cuando represento a una de las partes y el sistema de fichaje es SaaS, solicito al juez que el requerimiento de entrega de datos se dirija tanto a la empresa como al proveedor del servicio. La empresa proporciona los datos que ella ve; el proveedor proporciona los metadatos y logs a los que la empresa no tiene acceso.

Adquisición en sistemas on-premise (locales):

Para sistemas instalados en los servidores de la propia empresa, la adquisición es técnicamente más sencilla pero operativamente más delicada:

1. Acceso al servidor: Necesito acceso físico o remoto (SSH, RDP) al servidor donde se ejecuta el sistema de fichaje.
2. Identificación de la base de datos: Determinar qué motor de base de datos utiliza (PostgreSQL, MySQL, SQLite, SQL Server, Oracle) y localizar los archivos de datos.
3. Dump completo: Incluir no solo las tablas de fichajes, sino también las tablas de auditoría, las tablas de configuración (roles, permisos) y los logs de transacciones.
4. Preservación de WAL/binary logs: Estos archivos son críticos y pueden rotarse o eliminarse automáticamente. Su adquisición debe ser prioritaria.
5. Snapshots del disco: En entornos virtualizados (VMware, Hyper-V, KVM), un snapshot del disco completo del servidor es la mejor garantía de preservación integral.

3.2 Verificación de integridad con hash (MD5, SHA-1, SHA-256, SHA-512)

Una vez adquirida la base de datos, el siguiente paso es verificar si el sistema implementa algún mecanismo de integridad criptográfica.

Qué busco exactamente:

• Hash por registro: ¿Cada fila de la tabla de fichajes incluye un campo de hash? Si existe, ¿qué algoritmo se utiliza?
• Hash encadenado: ¿El hash de cada registro incorpora el hash del registro anterior? Esto crea una cadena donde modificar un solo registro rompe todos los posteriores.
• Firma del sistema: ¿Los hashes fueron generados por el servidor o por el dispositivo del usuario? Un hash generado en el servidor es más fiable porque el servidor está bajo control de la empresa (y por tanto, es auditable).

Proceso de verificación:

Para cada registro R[i] en la tabla de fichajes:
  1. Extraer los campos: timestamp, ID_empleado, tipo (entrada/salida), dispositivo, IP, ubicación
  2. Concatenar los campos en el mismo orden que utiliza el sistema
  3. Calcular SHA-256(concatenación)
  4. Comparar el hash calculado con el hash almacenado en R[i]
  5. Si no coinciden → registro R[i] ha sido modificado

Cuando un hash no coincide, la conclusión es inequívoca: ese registro ha sido alterado después de su creación. No importa quién lo hizo ni con qué intención; el dato es claro. Esta es la potencia de la verificación criptográfica: transforma una opinión pericial en una comprobación matemática.

3.3 Análisis de metadatos: timestamps de creación vs registro

Los metadatos son la información que el sistema genera automáticamente sobre cada registro, más allá de los datos introducidos por el usuario. Son especialmente reveladores porque, en muchos casos, el administrador que manipula registros no es consciente de que estos metadatos existen o no sabe cómo eliminarlos.

Metadatos clave que analizo:

• created_at: Fecha y hora en que la fila fue insertada en la base de datos. En un registro legítimo, esta fecha debería ser próxima a la hora del fichaje (con una diferencia de segundos o minutos). Si un registro que dice «entrada a las 09:00 del lunes» fue creado a las 23:47 del viernes anterior, hay un problema.
• updated_at: Si existe, indica cuándo se modificó por última vez la fila. En un sistema con integridad, este campo debería estar vacío o coincidir con created_at.
• ID de transacción: Los sistemas de bases de datos relacionales asignan un ID secuencial a cada transacción. Si los IDs no son secuenciales, puede indicar inserciones retroactivas.
• Información de sesión: Algunos sistemas registran qué usuario de base de datos ejecutó cada operación.

3.4 Análisis de logs de auditoría

Los logs de auditoría son, en mi experiencia, el elemento más revelador de un análisis forense de fichaje. Mientras que un administrador hábil puede modificar registros y ajustar metadatos, alterar los logs de auditoría de forma consistente es significativamente más difícil.

Qué busco en los logs:

1. Operaciones INSERT: Cada fichaje legítimo debería generar una operación INSERT en el log. Busco fichajes sin INSERT correspondiente (creados directamente en la base de datos).
2. Operaciones UPDATE: ¿Se han modificado registros? ¿Cuándo? ¿Por quién? ¿Con qué justificación?
3. Operaciones DELETE: ¿Se han eliminado fichajes? En un sistema bien diseñado, los fichajes nunca se borran (solo se marcan como anulados).
4. Gaps en la secuencia: Si el log tiene entradas numeradas (1, 2, 3, 7, 8, 9…), la ausencia de las entradas 4, 5 y 6 indica eliminación de logs.
5. Timestamps inconsistentes: Entradas de log cuyo timestamp no respeta el orden secuencial.

3.5 Búsqueda de registros eliminados (soft delete vs hard delete)

Cuando una empresa manipula registros de fichaje, a menudo necesita eliminar registros incómodos (por ejemplo, fichajes de fin de semana que probarían horas extras no remuneradas). La forma en que se produce esa eliminación determina si el perito puede recuperar los datos.

Soft delete (borrado lógico):

El registro no se elimina físicamente de la base de datos; se marca con un flag (por ejemplo, deleted = true o deleted_at = '2026-01-15 23:45:00'). Desde la perspectiva del usuario, el registro desaparece de la interfaz, pero sigue en la base de datos.

Detección forense: Buscar campos como deleted, is_active, status o deleted_at en la estructura de la tabla. Consultar todos los registros, incluidos los marcados como eliminados.

Hard delete (borrado físico):

El registro se elimina de la tabla. Sin embargo, dependiendo del sistema de base de datos:

• PostgreSQL: Los registros borrados pueden permanecer en el espacio libre de las páginas de datos hasta que se ejecute un VACUUM.
• SQLite: Los registros borrados permanecen en las páginas libres de la base de datos hasta que se sobrescriben con nuevos datos. Herramientas forenses como sqlite3_analyzer o undark pueden recuperarlos.
• MySQL/MariaDB: Con el motor InnoDB, los registros borrados pueden recuperarse del redo log o del undo tablespace.

3.6 Análisis de patrones estadísticos (regularidad sospechosa)

Esta es una de las técnicas más reveladoras y menos conocidas. Se basa en un principio simple: los datos reales son irregulares; los datos fabricados tienden a la regularidad artificial.

Patrones que delatan la manipulación:

• Hora exacta de fichaje: En un sistema real, es estadísticamente improbable que un trabajador fiche siempre a las 09:00:00 exactas. La distribución natural muestra variabilidad: 08:57, 09:03, 09:01, 08:59. Si un empleado tiene 200 fichajes y todos son a las 09:00:00 y 18:00:00, los datos fueron generados artificialmente.
• Distribución de últimos dígitos: Los segundos del timestamp deberían seguir una distribución aproximadamente uniforme (00 a 59). Si el 80 % de los fichajes ocurren en segundo :00, los datos son sospechosos.
• Ausencia de variabilidad semanal: Los fichajes reales muestran patrones distintos según el día de la semana (lunes se llega un poco más tarde, viernes se sale un poco antes). La ausencia total de variabilidad sugiere datos fabricados.
• Regularidad extrema en la duración de la jornada: Si la duración registrada es exactamente 8:00:00 todos los días, sin excepción, durante meses, los datos no son reales.
• Ley de Benford: El primer dígito de los minutos debería seguir una distribución no uniforme (la ley de Benford). Un dataset manipulado tiende a una distribución uniforme.
• Clusters de fichajes al mismo segundo: Si 15 empleados fichan todos los días al mismo segundo exacto (por ejemplo, 09:00:00), es sospechoso. En un sistema real con terminal compartido, los fichajes se distribuyen a lo largo de varios minutos porque los empleados hacen cola.
• Ausencia de fichajes olvidados: En cualquier empresa, un porcentaje de trabajadores olvida fichar de vez en cuando (entre un 2 % y un 5 % de los días, según estudios del sector). Un dataset sin ningún fichaje olvidado en 12 meses es estadísticamente improbable.
• Correlación temporal entre fichajes y festivos/vacaciones: Un dataset fabricado puede incluir fichajes en días festivos o durante las vacaciones del trabajador si el generador no verificó el calendario.

Umbrales estadísticos que utilizo:

En mis informes, aplico tests estadísticos con umbrales documentados que permiten al tribunal comprender el nivel de confianza de la conclusión:

Estos umbrales se basan en mi experiencia analizando datasets de empresas de diversos sectores. No son absolutos (cada empresa tiene sus particularidades), pero proporcionan un marco de referencia que refuerza la objetividad del informe pericial.

Cómo presento esta evidencia:

En mis informes periciales, incluyo gráficos de distribución que permiten al juez visualizar la diferencia entre un patrón natural y uno artificial. Un histograma que muestra que el 95 % de los fichajes ocurren en el segundo :00 es enormemente persuasivo, incluso para un tribunal no técnico.

3.7 Correlación con fuentes externas

La correlación consiste en contrastar los fichajes con otras fuentes de datos que registran la presencia o actividad del trabajador. Si un empleado fichó su entrada a las 09:00 pero su primera conexión VPN fue a las 11:30, hay una discrepancia que requiere explicación.

Esta técnica es especialmente útil cuando el sistema de fichaje no tiene integridad criptográfica y el análisis de metadatos no es concluyente. La correlación aporta evidencia circunstancial que, acumulada, puede ser tan persuasiva como una verificación de hash.

Dedico una sección completa más adelante a las fuentes de evidencia complementaria y las técnicas de correlación.

Ejemplo de correlación reveladora:

En un caso reciente (datos anonimizados), el sistema de fichaje de una empresa de logística mostraba jornadas regulares de 8 horas para un conductor. Sin embargo:

• Los datos GPS del vehículo corporativo mostraban rutas que se extendían 2-3 horas más allá de la hora de «salida» registrada.
• Las llamadas telefónicas del conductor al centro de control se producían hasta las 21:00, pese a que su fichaje de salida marcaba las 18:00.
• Los albaranes de entrega firmados por clientes tenían timestamps de las 19:00-20:00.

La acumulación de estas tres fuentes independientes de evidencia permitió demostrar que los fichajes de salida habían sido sistemáticamente manipulados. El conductor recibió el pago de más de 400 horas extras acumuladas en 14 meses.

Matriz de correlación temporal:

La tabla anterior es el tipo de análisis que presento en mis informes periciales. La inconsistencia a las 18:00 (fichaje de salida mientras el GPS muestra que el vehículo sigue en ruta) es la evidencia clave.

4. Análisis de metadatos: la huella invisible

Los metadatos son, literalmente, «datos sobre los datos». Son la huella invisible que todo sistema informático genera automáticamente y que, en muchos casos, ni el usuario ni el administrador del sistema saben que existe. Para un perito informático forense, los metadatos son oro puro.

4.1 Qué son los metadatos en un sistema de fichaje

En el contexto de un sistema de fichaje, los metadatos incluyen toda la información que rodea al acto de fichar, más allá del dato visible (hora de entrada/salida). Ejemplos:

• Timestamp de creación del registro en la base de datos (diferente de la hora de fichaje declarada).
• Dirección IP desde la que se realizó la operación.
• User Agent del navegador o identificador del dispositivo móvil.
• Coordenadas GPS y precisión del posicionamiento.
• ID de sesión del usuario que realizó la operación.
• ID secuencial de la transacción en la base de datos.
• Versión de la aplicación utilizada para fichar.

4.2 Timestamps de creación, modificación y acceso

Los timestamps son el metadato más revelador en un análisis forense de fichaje. Existen tres tipos principales:

Timestamp de creación (created_at / INSERT timestamp):

Es la fecha y hora exacta en que el registro fue insertado en la base de datos. En un fichaje legítimo, este timestamp debería estar muy próximo a la hora del fichaje declarada. Si un empleado ficha su entrada a las 09:00 horas, el registro debería crearse en la base de datos entre las 09:00:00 y las 09:00:05 (margen de latencia de red).

Señales de alerta en timestamps de creación:

• Registro creado horas o días después de la hora de fichaje declarada.
• Múltiples registros de diferentes empleados creados en el mismo segundo (indicativo de inserción masiva retroactiva).
• Registros creados fuera del horario laboral (por ejemplo, a las 03:00 de la madrugada del domingo).
• Registros de toda una semana creados el viernes por la noche.

Timestamp de modificación (updated_at / last_modified):

Indica cuándo se modificó por última vez el registro. En un sistema bien diseñado, los fichajes no deberían modificarse nunca. Si se detectan modificaciones, hay que investigar quién las hizo y por qué.

Timestamp de acceso (accessed_at / last_read):

Menos común, indica cuándo se leyó por última vez el registro. Puede revelar si alguien revisó un registro específico antes de modificarlo.

4.3 User Agent y dispositivo de origen

Cuando el fichaje se realiza desde una aplicación móvil o un navegador web, el sistema puede registrar el User Agent: una cadena de texto que identifica el tipo de dispositivo, sistema operativo y versión del navegador.

Utilidad forense del User Agent:

• Consistencia de dispositivo: Si un empleado siempre ficha desde un iPhone 15 Pro (User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_3 like Mac OS X)...) y de repente un fichaje proviene de Python-urllib/3.9, ese registro fue generado programáticamente, no desde la app de fichaje.
• Detección de emuladores: Los emuladores de Android (BlueStacks, Genymotion) generan User Agents característicos que un perito puede identificar.
• Versión de la app: Si la app de fichaje se actualizó en enero y un fichaje de diciembre muestra la versión de febrero, el registro fue creado retroactivamente.

4.4 Dirección IP y geolocalización

La dirección IP desde la que se realiza el fichaje es un metadato enormemente útil para la correlación:

• IP de la empresa vs IP doméstica: Si la política exige fichaje presencial y un registro proviene de una IP residencial (rangos de operadores domésticos como Movistar, Vodafone, Orange), hay una inconsistencia.
• IP de VPN: Las conexiones VPN corporativas son trazables. Si el fichaje de «entrada a las 09:00» no tiene VPN asociada y el fichaje de «inicio de VPN» es a las 11:30, la discrepancia es evidente.
• Geolocalización por IP: Las bases de datos GeoIP permiten determinar la ubicación aproximada del fichaje. Un fichaje supuestamente realizado en la oficina de Madrid pero cuya IP geolocaliza en Málaga es cuestionable.

4.5 Inconsistencias reveladoras: fichaje «en oficina» desde IP doméstica

Permíteme ilustrar con un ejemplo real (anonimizado) de mi práctica profesional:

En un caso de reclamación de horas extras, la empresa presentó los registros de fichaje mostrando jornadas estrictas de 8 horas. El trabajador, sin embargo, alegaba jornadas de 10-12 horas con horas extras no registradas.

Al analizar los metadatos del sistema de fichaje:

1. Los fichajes de «salida» a las 18:00 tenían como IP de origen la IP fija de la oficina de la empresa.
2. Sin embargo, los correos electrónicos del trabajador enviados entre las 18:00 y las 22:00 provenían de la misma IP de la oficina.
3. Los logs del punto de acceso WiFi corporativo mostraban que el dispositivo del trabajador estuvo conectado hasta las 22:15.
4. El fichaje de «salida» a las 18:00 fue creado en la base de datos a las 18:00:00 exactas (no a las 18:00:23 o 18:01:15, como sería normal).
5. El ID de transacción del fichaje de salida era posterior al de otros registros creados a las 18:30.

Estas cinco inconsistencias, ninguna de las cuales era visible para el usuario del sistema, permitieron concluir con alto grado de certeza que los fichajes de salida habían sido manipulados retroactivamente. El tribunal aceptó las conclusiones del informe pericial.

4.6 Herramientas de extracción de metadatos

Las herramientas que utilizo para extraer y analizar metadatos varían según el tipo de sistema:

Nota sobre la admisibilidad de los metadatos como prueba:

Los metadatos, por sí solos, constituyen evidencia circunstancial. Un único metadato inconsistente (por ejemplo, un created_at que no coincide con la hora del fichaje) puede tener explicaciones inocentes (un retraso en la sincronización del servidor, un cambio de zona horaria, una migración de datos). Por eso, en mis informes siempre presento los metadatos en contexto, combinados con otros indicios, y cuantifico la probabilidad de que las inconsistencias detectadas se deban a causas técnicas legítimas vs manipulación deliberada.

Cuando presento el análisis de metadatos ante un tribunal, utilizo un formato que destaca tanto los hallazgos como su significado:

«De los 4.720 registros analizados, 312 presentan una discrepancia entre el timestamp de fichaje declarado y el timestamp de creación del registro en la base de datos superior a 24 horas. Todos estos 312 registros corresponden al mismo trabajador y fueron creados en una ventana de 47 minutos el día 15 de enero de 2026, según los IDs de transacción consecutivos y el timestamp de inserción en la tabla audit_log. La probabilidad de que esta coincidencia se deba a un error técnico del sistema es negligible.»

Este formato combina el hallazgo técnico con su interpretación, manteniendo la objetividad que se espera del perito.

5. Hash criptográfico: la prueba de no manipulación

Si existe un elemento técnico que marca la diferencia entre un sistema de fichaje con garantías forenses y uno sin ellas, es el hash criptográfico. En esta sección explico en profundidad qué es, cómo funciona y por qué su presencia (o ausencia) determina la solidez de un registro de fichaje como prueba digital.

5.1 Qué es un hash y por qué es fundamental

Un hash criptográfico es una función matemática unidireccional que transforma un conjunto de datos de longitud arbitraria en una cadena de longitud fija. Sus propiedades fundamentales son:

• Determinismo: Los mismos datos de entrada siempre producen el mismo hash.
• Unidireccionalidad: Dado un hash, es computacionalmente imposible obtener los datos originales.
• Resistencia a colisiones: Es extremadamente improbable que dos conjuntos de datos diferentes produzcan el mismo hash.
• Efecto avalancha: Un cambio mínimo en los datos de entrada (un solo bit) produce un hash completamente diferente.

Ejemplo práctico:

Imaginemos un fichaje con estos datos:

• Empleado: 12345
• Tipo: entrada
• Fecha/hora: 2026-03-15 09:01:23
• Dispositivo: iPhone 15 Pro
• IP: 83.45.123.67

El hash SHA-256 de estos datos concatenados produce una cadena de 64 caracteres hexadecimales como:

a7f3b2c1e8d9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5

Si alguien modifica la hora de 09:01:23 a 09:00:00, el hash resultante sería completamente diferente:

9c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5

La comparación es binaria: el hash coincide o no coincide. No hay área gris. Esto convierte la verificación de integridad de hash en una de las pruebas más potentes que un perito puede presentar ante un tribunal.

5.2 Algoritmos: MD5 (débil), SHA-1 (deprecado), SHA-256 (estándar), SHA-512

No todos los algoritmos de hash ofrecen las mismas garantías. La elección del algoritmo es relevante tanto técnica como jurídicamente:

Mi recomendación profesional: SHA-256 es el estándar que debería utilizar todo sistema de fichaje con pretensiones de integridad forense. Ofrece un equilibrio óptimo entre seguridad y rendimiento. SHA-512 es innecesario para este caso de uso; MD5 y SHA-1 no deberían utilizarse como mecanismo principal de integridad.

¿Y si el sistema usa MD5?

No significa automáticamente que la integridad sea verificable. Un perito debe documentar que el algoritmo utilizado tiene debilidades conocidas. Sin embargo, en la práctica, un MD5 intacto sigue siendo mejor que la ausencia total de hash: las colisiones de MD5 requieren ataques deliberados y sofisticados que es improbable que un administrador de recursos humanos ejecute.

5.3 Cómo funciona el encadenamiento de hashes (hash chain)

El encadenamiento de hashes eleva la integridad a un nivel superior. En lugar de calcular el hash de cada registro de forma aislada, el hash de cada registro incorpora el hash del registro anterior:

Hash[1] = SHA-256(datos_registro_1)
Hash[2] = SHA-256(datos_registro_2 + Hash[1])
Hash[3] = SHA-256(datos_registro_3 + Hash[2])
...
Hash[n] = SHA-256(datos_registro_n + Hash[n-1])

Ventaja fundamental: Si se modifica el registro número 500 de una cadena de 10.000, no solo falla la verificación del registro 500, sino también la de los registros 501, 502, …, 10.000. La manipulación de un solo registro rompe toda la cadena posterior.

Esto hace que la manipulación retroactiva sea enormemente costosa: para que pase desapercibida, habría que recalcular todos los hashes desde el registro modificado hasta el último. Y si el sistema publica periódicamente un «hash de anclaje» (por ejemplo, enviando el hash del último registro al final de cada mes a una dirección de correo certificada), ni siquiera eso es viable.

5.4 Verificación práctica: recalcular y comparar

Como perito, el proceso de verificación que ejecuto es sistemático y reproducible:

Paso 1: Identificar la estructura de hash del sistema. ¿Qué campos se incluyen en el cálculo? ¿En qué orden? ¿Se usa encadenamiento?

Paso 2: Extraer la tabla completa de fichajes, incluyendo los hashes almacenados.

Paso 3: Para cada registro, recalcular el hash utilizando los datos actuales y el mismo algoritmo.

Paso 4: Comparar hash recalculado con hash almacenado.

Paso 5: Documentar los resultados:

• Registros verificados (hash coincide): N
• Registros con integridad comprometida (hash no coincide): M
• Registros sin hash (si los hubiera): P

Paso 6: Para cada registro con hash comprometido, investigar qué campo fue modificado (si es posible reconstruirlo a partir de logs o backups).

Ejemplo de verificación en la práctica:

En un caso real (anonimizado), analicé un sistema de fichaje que implementaba SHA-256 sin encadenamiento. De 4.720 registros analizados:

Los 47 registros con hash comprometido correspondían a fichajes de salida del mismo trabajador, todos modificados en la misma sesión de base de datos (mismo transaction_id), 3 días después del despido del trabajador. Los hashes originales (recuperados del backup semanal) mostraban horas de salida entre las 20:00 y las 21:30; los hashes actuales reflejaban salidas a las 18:00.

Este análisis, que requirió menos de 2 horas de trabajo técnico, aportó una prueba inequívoca de manipulación que el tribunal aceptó sin objeción.

5.5 Qué pasa cuando un hash no coincide

Cuando detecto que un hash no coincide, las implicaciones son serias:

1. Certeza técnica de modificación: El registro fue alterado después de su creación. No hay ambigüedad.
2. No determina quién lo hizo: El hash demuestra la manipulación, pero no identifica al autor. Para eso necesito los logs de auditoría.
3. No determina qué se modificó: A menos que se disponga de una copia anterior (backup) para comparar, el hash solo indica que algo cambió, no qué campo ni en qué sentido.
4. Invalida la cadena posterior: Si el sistema usa encadenamiento, todos los registros posteriores al manipulado tienen hashes inválidos, aunque sus datos no hayan sido modificados.

En mi informe pericial, presento esta información con tablas detalladas y gráficos que muestran claramente qué registros mantienen su integridad y cuáles la han perdido.

5.6 Sistemas que implementan hash por registro: Daltico Equipo

Las características forenses específicas que hacen de esta solución un referente incluyen:

• Hash SHA-256 por cada registro individual: No un hash del archivo completo (que no protege contra manipulaciones internas), sino un hash por cada fichaje.
• Encadenamiento de hashes: Cada hash incorpora el anterior, creando una cadena inmutable.
• Contexto evidencial completo: Junto al hash, se almacena IP, dispositivo, geolocalización y timestamp del servidor.
• Logs de auditoría INSERT-only: Las operaciones de auditoría solo admiten inserciones, nunca actualizaciones ni borrados.
• Workflow de corrección obligatorio: Si es necesario corregir un fichaje (error legítimo), se genera una solicitud de modificación que requiere aprobación del responsable, con motivo obligatorio. La corrección no sobrescribe el registro original: crea un nuevo registro de corrección vinculado al original.

Este enfoque convierte el sistema de fichaje en una fuente de evidencia digital robusta, verificable y admisible en sede judicial.

6. Logs de auditoría: el testigo silencioso

Si el hash criptográfico es la prueba de integridad, los logs de auditoría son el testigo que cuenta la historia completa. Un hash te dice si algo cambió; un log te dice quién lo cambió, cuándo y, en los mejores sistemas, por qué.

6.1 Qué debe contener un log de auditoría

Un log de auditoría forense-ready debe registrar, como mínimo:

6.2 Inmutabilidad: INSERT-only vs logs editables

La inmutabilidad de los logs es el criterio que separa un sistema auditable de uno que no lo es.

Logs INSERT-only (inmutables):

En este modelo, los logs solo admiten operaciones de inserción. Una vez escrita una entrada de log, no puede modificarse ni eliminarse. Técnicamente, esto se implementa mediante:

• Permisos de base de datos que solo permiten INSERT en la tabla de logs (sin UPDATE ni DELETE para ningún usuario, incluido el administrador).
• Almacenamiento en un servicio externo de logging (por ejemplo, un servidor syslog remoto o un servicio cloud como CloudWatch).
• Firma criptográfica de cada entrada de log.

Logs editables (vulnerables):

Si el administrador del sistema puede modificar o eliminar entradas del log, todo el mecanismo de auditoría pierde su valor. Un administrador que modifica un fichaje y luego borra la entrada de log correspondiente no deja rastro (al menos, no en el propio sistema).

Lo que busco como perito: Verifico los permisos de la tabla de logs en la base de datos. Si existe un GRANT que permita UPDATE o DELETE sobre la tabla de auditoría para cualquier usuario, documento esta vulnerabilidad en mi informe.

Implementaciones técnicas de inmutabilidad que verifico:

En la práctica, los sistemas más robustos combinan varios mecanismos. Por ejemplo, logs INSERT-only en la base de datos local + copia en tiempo real a un servicio externo de logging + hash encadenado de las entradas. Esta defensa en profundidad garantiza que, incluso si un mecanismo falla, los demás siguen protegiendo la integridad del log.

Verificación de permisos — Lo que hago concretamente:

Para PostgreSQL, ejecuto consultas sobre las tablas de sistema (pg_catalog) para listar los privilegios de cada usuario sobre la tabla de logs de auditoría. Si encuentro que algún usuario tiene privilegios de UPDATE o DELETE, lo documento como vulnerabilidad. Para MySQL, utilizo SHOW GRANTS FOR 'usuario'@'host' sobre todos los usuarios con acceso a la base de datos del sistema de fichaje.

Adicionalmente, verifico si existen triggers de protección que impidan DELETE o UPDATE en la tabla de logs. Un trigger bien implementado lanza una excepción (RAISE EXCEPTION en PostgreSQL, SIGNAL SQLSTATE en MySQL) cuando alguien intenta modificar o eliminar una entrada del log, incluso si tiene permisos para hacerlo.

6.3 Análisis de gaps y secuencias rotas

Cada entrada de un log de auditoría debería tener un identificador secuencial (auto-incremento). La secuencia debería ser continua: 1, 2, 3, 4, 5, …

Si detecto una secuencia como 1, 2, 3, 7, 8, 9…, las entradas 4, 5 y 6 fueron eliminadas. Esto es una evidencia directa de manipulación del propio log de auditoría, lo cual es especialmente grave porque implica un intento deliberado de ocultar acciones.

Técnicas de detección de gaps:

1. Consultar el ID máximo y contar el número total de registros. Si MAX(id) - MIN(id) + 1 > COUNT(*), hay gaps.
2. Buscar saltos en la secuencia con una query que identifique id donde id + 1 no existe en la tabla.
3. Verificar si el motor de base de datos reutiliza IDs eliminados (en algunos motores, el auto-incremento no retrocede tras un DELETE).

Ejemplo real de gaps reveladores:

En un caso de un restaurante que utilizaba un sistema de fichaje basado en SQLite, el log de auditoría mostraba la siguiente secuencia de IDs:

..., 8.234, 8.235, 8.236, 8.241, 8.242, 8.243, ...

Los IDs 8.237 a 8.240 (4 entradas) habían sido eliminados. Al recuperar los registros del espacio libre de SQLite con undark, las cuatro entradas correspondían a operaciones UPDATE ejecutadas a las 02:34 de la madrugada del domingo. Las operaciones modificaban los fichajes de salida de cuatro camareros, cambiándolos de las 01:30 (hora real de cierre del restaurante los sábados) a las 23:00. El propietario del restaurante no solo había manipulado los fichajes: había manipulado también el log de auditoría para cubrir la manipulación. Pero no contó con que SQLite conserva los datos eliminados en el espacio libre del archivo hasta que se sobrescriben.

6.4 Detección de modificaciones retroactivas

Las modificaciones retroactivas son la forma más común de manipulación de fichajes por parte de la empresa. El patrón típico es:

1. El trabajador ficha su salida a las 20:30.
2. Al generar el informe mensual, la empresa modifica la hora de salida a 18:00.
3. Si hay log de auditoría, el log registra la modificación.
4. Si el log es editable, la empresa borra la entrada de log.

Cómo lo detecto cuando el log ha sido manipulado:

Incluso cuando se han borrado entradas del log, pueden quedar rastros:

• Binary log de MySQL/MariaDB: Si está habilitado, registra todas las operaciones DML (INSERT, UPDATE, DELETE) a nivel de servidor. Es independiente del log de la aplicación.
• WAL de PostgreSQL: El Write-Ahead Log registra todas las modificaciones antes de aplicarlas. Con configuración adecuada, se pueden recuperar operaciones pasadas.
• WAL de SQLite: Similar al anterior, el Write-Ahead Log de SQLite puede contener operaciones que la aplicación creía eliminadas.
• Backups: Si existen copias de seguridad anteriores a la manipulación, la comparación con los datos actuales revela las diferencias.

6.5 Quién modificó qué y cuándo: la trazabilidad

La trazabilidad completa requiere que cada modificación pueda atribuirse a un usuario concreto, en un momento concreto, con un motivo documentado. En los sistemas más avanzados, como Daltico Equipo, la trazabilidad es parte integral del diseño:

1. Toda modificación requiere una solicitud formal con motivo justificado.
2. La solicitud debe ser aprobada por un responsable diferente del solicitante (segregación de funciones).
3. El registro original se conserva intacto; la corrección se vincula como un registro adicional.
4. El log de auditoría registra tanto la solicitud como la aprobación y la ejecución.

Este nivel de trazabilidad transforma cada modificación en un proceso documentado que el perito puede reconstruir paso a paso.

7. Correlación con otras fuentes de evidencia

Cuando el sistema de fichaje no dispone de integridad criptográfica y los logs son insuficientes, la correlación con fuentes externas se convierte en la técnica principal del perito. Consiste en contrastar los datos de fichaje con otras fuentes de información que registran, de forma independiente, la presencia o actividad del trabajador.

7.1 Registros de acceso físico (tornos, tarjetas)

Los sistemas de control de acceso físico (tornos de entrada, lectores de tarjeta en puertas) generan sus propios registros, generalmente en un sistema independiente del de fichaje laboral. La comparación entre ambos puede revelar discrepancias.

Ejemplo: Si el registro de fichaje indica que el trabajador salió a las 18:00, pero el torno de salida del edificio registra el paso de su tarjeta a las 21:15, hay una inconsistencia clara que el perito documenta en su informe.

Precaución: Los sistemas de acceso físico también pueden ser manipulados por el administrador. La correlación es más sólida cuanto más independientes sean los sistemas.

Ejemplo detallado de correlación con control de acceso:

En un caso que analicé para una empresa con sede en un polígono industrial de Madrid, el sistema de acceso al edificio era gestionado por la empresa propietaria del inmueble (no por la empresa empleadora). Esto lo convertía en una fuente de evidencia especialmente valiosa porque la empresa empleadora no tenía capacidad de manipular esos registros.

La comparación reveló el siguiente patrón para un trabajador durante un mes completo:

El patrón era claro: los fichajes de entrada eran coherentes con los registros del torno, pero los fichajes de salida se habían establecido sistemáticamente a las 18:00 mientras que los registros del torno mostraban salidas 2-3 horas más tarde. En 22 días laborables del mes analizado, la discrepancia acumulada fue de 54 horas y 23 minutos.

7.2 Logs de VPN y conexiones remotas

Para trabajadores que se conectan remotamente, los logs de VPN son una fuente de evidencia extraordinariamente valiosa:

• Hora de conexión y desconexión: Muestra cuándo el trabajador estaba efectivamente conectado a los sistemas de la empresa.
• Duración de la sesión: Complementa el registro de fichaje.
• IP de origen: Confirma la ubicación del trabajador (domicilio, coworking, etc.).
• Volumen de datos: Un trabajador que supuestamente terminó a las 18:00 pero cuya VPN muestra transferencia de datos hasta las 22:00 estaba trabajando.

7.3 Timestamps de emails enviados y recibidos

Los correos electrónicos tienen timestamps fiables generados por el servidor de correo (no por el dispositivo del usuario). Los headers del email incluyen:

• Date: Fecha y hora de envío según el cliente de correo.
• Received: Cadena de servidores por los que pasó el email, cada uno con su timestamp.
• X-Originating-IP: IP desde la que se envió el correo.

Relevancia forense: Si un trabajador envió correos electrónicos de trabajo entre las 18:00 y las 22:00, esos correos prueban actividad laboral independientemente de lo que diga el registro de fichaje.

La STS de enero de 2026 que reconoció que responder al teléfono móvil fuera del horario constituye hora extra se apoyó, entre otras evidencias, en los registros de llamadas y mensajes.

7.4 Conexiones WiFi corporativas

Los puntos de acceso WiFi corporativos registran las conexiones de los dispositivos (por su dirección MAC). Estos logs son particularmente útiles porque:

• Son generados por infraestructura de red, no por software de la empresa manipulable.
• Registran la hora de conexión, desconexión y, en algunos casos, el volumen de datos.
• Están vinculados a un dispositivo concreto (dirección MAC), no a un usuario (que podría delegar el fichaje).

Limitación: La dirección MAC puede falsificarse (MAC spoofing), aunque esto requiere conocimientos técnicos que la mayoría de trabajadores no poseen.

7.5 Datos GPS de dispositivos corporativos

Si la empresa proporciona un teléfono corporativo o un vehículo con GPS, los datos de localización constituyen evidencia complementaria:

• Histórico de ubicación del dispositivo móvil: Android e iOS registran la ubicación del dispositivo de forma continua.
• GPS del vehículo: Los registros de flota documentan hora de inicio y fin de ruta, ubicación y paradas.
• Google Maps Timeline: Si el trabajador usa su cuenta de Google en el dispositivo corporativo, el historial de ubicaciones puede recuperarse.

7.6 Mensajes WhatsApp fuera de horario como prueba de horas extras

Los mensajes de WhatsApp enviados o recibidos fuera del horario laboral son, cada vez con más frecuencia, la prueba que inclina la balanza en las reclamaciones de horas extras.

Jurisprudencia relevante:

• Múltiples sentencias de TSJ reconocen que los mensajes de WhatsApp del jefe a las 22:00 pidiendo informes o resolución de incidencias constituyen tiempo de trabajo efectivo.
• La sentencia de enero de 2026 extendió este criterio a las llamadas de teléfono: responder al móvil corporativo fuera de horario, si es una pauta habitual, genera horas extras.

Requisitos para que los mensajes WhatsApp sean admitidos como prueba:

1. Autenticidad: Debe demostrarse que los mensajes son auténticos (no manipulados). Aquí es donde interviene el peritaje forense de WhatsApp.
2. Relevancia: Los mensajes deben estar relacionados con la actividad laboral.
3. Cadena de custodia: Los mensajes deben presentarse con un informe pericial que garantice su integridad.

7.7 Tabla resumen: fuentes de evidencia complementaria

7.8 Metodología de correlación temporal paso a paso

La correlación temporal no es simplemente «comparar dos fechas». Es un proceso metódico que sigo en cada peritaje:

Paso 1 — Recopilación de fuentes:

Identifico todas las fuentes de datos disponibles que registren actividad del trabajador. Cuantas más fuentes independientes entre sí, más robusta es la conclusión. En un caso típico, trabajo con 3-5 fuentes simultáneamente.

Paso 2 — Normalización temporal:

Todas las fuentes deben expresarse en la misma zona horaria. Puede parecer trivial, pero es una fuente frecuente de errores: el servidor de correo puede usar UTC, el sistema de fichaje CET/CEST, la VPN GMT+1, y el GPS UTC. Si no se normaliza, las comparaciones son incorrectas.

Paso 3 — Creación del supertimeline:

Combino todos los eventos de todas las fuentes en una única línea temporal ordenada cronológicamente. Cada evento se etiqueta con su fuente de origen. Utilizo log2timeline/plaso para datasets grandes y hojas de cálculo para datasets manejables.

Paso 4 — Detección de inconsistencias:

Busco puntos donde las fuentes se contradicen:

• Fichaje de salida a las 18:00, pero email enviado a las 20:15 desde la misma IP de la oficina.
• Fichaje de entrada a las 09:00, pero primera conexión WiFi a las 10:30.
• Fichaje «presencial», pero conexión VPN desde IP doméstica.

Paso 5 — Cuantificación:

Para cada inconsistencia detectada, calculo la diferencia temporal y la acumulo. El resultado final es una cifra concreta: «el trabajador estuvo activo un promedio de 2 horas y 15 minutos diarios más allá de la hora de salida registrada, durante 147 días laborables, acumulando un total estimado de 330,75 horas no registradas.»

Paso 6 — Presentación al tribunal:

Preparo una tabla resumen con los días más representativos (no los 147, sino una muestra de 10-15 que ilustren el patrón) y un gráfico de barras que compare la jornada registrada con la jornada estimada según la correlación. Este formato visual es enormemente efectivo ante un tribunal no técnico.

7.9 Limitaciones de la correlación

Es importante documentar también las limitaciones:

• La correlación no es causalidad: Que un trabajador envíe un email a las 21:00 no prueba que estuviera trabajando por orden de la empresa. Podría ser iniciativa propia.
• Fuentes no siempre disponibles: El trabajador puede no tener acceso a los logs de VPN o WiFi sin requerimiento judicial.
• Precisión temporal variable: El GPS tiene precisión de segundos, pero el WiFi solo registra conexión/desconexión (no actividad continua).
• Datos parciales: Las fuentes pueden no cubrir todo el período en disputa (logs rotados, backups eliminados, retención limitada).

Estas limitaciones se documentan en el informe pericial para que el tribunal pueda valorar adecuadamente el alcance y fiabilidad de las conclusiones.

8. Casos reales de fichajes manipulados en tribunales

La jurisprudencia española sobre manipulación de registros de fichaje es rica y reveladora. A continuación, analizo las sentencias más relevantes desde la perspectiva del perito informático forense.

8.1 STS 1161/2024: fiabilidad del sistema de registro

La Sentencia del Tribunal Supremo 1161/2024, de 24 de septiembre de 2024, es la referencia fundamental. El TS estableció que el sistema de registro de jornada debe ser «objetivo, fiable y accesible», alineándose con la doctrina del TJUE (C-55/18).

Lo que esta sentencia significa para el peritaje:

• El tribunal puede (y debe) evaluar la fiabilidad técnica del sistema de fichaje. No basta con que exista un registro: debe ser técnicamente robusto.
• La empresa tiene la carga de demostrar que su sistema es fiable. Si no puede hacerlo, el registro pierde valor probatorio.
• Un informe pericial que demuestre vulnerabilidades técnicas del sistema puede ser suficiente para desacreditar los registros presentados por la empresa.

8.2 TSJC: sin registro equivale a pago de horas extras

Diversas sentencias del Tribunal Superior de Justicia de Cataluña (TSJC) han establecido una presunción que favorece al trabajador: si la empresa no puede presentar un registro de jornada fiable, se presumen ciertas las horas extras alegadas por el trabajador.

Esta presunción no es absoluta (la empresa puede aportar otras pruebas), pero invierte la carga probatoria de forma significativa. En la práctica, obliga a la empresa a demostrar que no hubo horas extras, en lugar de obligar al trabajador a demostrar que sí las hubo.

Implicación para el peritaje: Cuando un perito demuestra que el sistema de fichaje de la empresa es técnicamente vulnerable (sin logs, sin hash, sin trazabilidad), está proporcionando al tribunal un fundamento técnico para activar esta inversión de la carga probatoria.

8.3 TSJ Madrid 6489/2024: cuaderno manuscrito invierte carga de prueba

La sentencia del TSJ de Madrid 6489/2024 representa un caso paradigmático. Un trabajador aportó un cuaderno manuscrito donde anotaba sus horas de entrada y salida diariamente. La empresa, que utilizaba un sistema de fichaje electrónico, impugnó el cuaderno alegando que no era fiable.

El tribunal dictaminó que:

1. El cuaderno del trabajador, aunque rudimentario, constituía un indicio razonable de las horas extras realizadas.
2. Ante ese indicio, la empresa debía demostrar la fiabilidad de su sistema electrónico.
3. La empresa no pudo demostrar que su sistema fuera inmune a manipulaciones (no tenía logs de auditoría ni hash de integridad).
4. Se invirtió la carga de la prueba y se condenó a la empresa al pago de las horas extras.

Lección forense: Un sistema de fichaje electrónico sin garantías forenses puede perder frente a un cuaderno manuscrito si el trabajador aporta indicios razonables.

8.4 Sentencia enero 2026: responder al móvil fuera de horario constituye hora extra

Una sentencia de enero de 2026 (ampliamente difundida en medios especializados) estableció que la atención de llamadas y mensajes del trabajo fuera del horario laboral, cuando es una pauta habitual exigida por la empresa, constituye tiempo de trabajo efectivo y genera derecho a horas extras.

Relevancia para el peritaje de fichaje:

• Los registros de llamadas del operador móvil se convirtieron en prueba clave.
• Los mensajes de WhatsApp del supervisor fueron autenticados mediante peritaje informático.
• El registro de fichaje de la empresa mostraba jornadas de 8 horas, pero las llamadas y mensajes fuera de horario evidenciaban jornadas efectivas de 10-11 horas.

8.5 Caso típico: Excel manipulado en hostelería

La hostelería es uno de los sectores con mayor litigiosidad en materia de horas extras. Un caso frecuente que encuentro en mi práctica profesional (datos anonimizados):

Situación: Trabajador de restaurante reclama 2 años de horas extras no remuneradas. La empresa presenta un archivo Excel con registros de jornada de 8 horas exactas.

Análisis forense del Excel:

1. Fecha de creación del archivo: 3 días antes de la conciliación ante el SMAC (no coincide con el supuesto inicio del registro, 2 años antes).
2. Metadatos de autor: El archivo fue creado por «Asesoría García» (la gestoría de la empresa), no por el sistema de fichaje.
3. Uniformidad sospechosa: Todos los registros muestran exactamente 8:00:00 de jornada. Sin variación alguna en 500 registros consecutivos. Estadísticamente imposible en un registro real.
4. Sin logs, sin hash, sin versiones: El archivo no tiene historial de versiones ni ningún mecanismo de integridad.

Conclusión del informe pericial: Los registros fueron generados retroactivamente en una fecha posterior a los hechos registrados, probablemente con fines probatorios. El tribunal aceptó esta conclusión y condenó a la empresa.

8.6 Caso típico: app de fichaje sin logs auditables

Situación: Empresa tecnológica con 50 empleados utiliza una app de fichaje conocida. Trabajador despedido reclama horas extras. La empresa presenta los registros de la app mostrando jornadas regulares.

Análisis forense de la app:

1. El panel de administración permite modificar cualquier registro sin generar entrada de log.
2. No existe hash ni firma criptográfica por registro.
3. La base de datos (PostgreSQL en AWS RDS) muestra que 47 registros del trabajador fueron modificados en la misma transacción, 3 días después del despido. El campo updated_at revela la fecha real de modificación.
4. Los logs de acceso de AWS RDS confirman que la sesión de base de datos fue iniciada por la IP del CTO de la empresa.

Conclusión del informe pericial: 47 fichajes del trabajador fueron alterados retroactivamente tras el despido. Las horas de salida originales (recuperables del binary log de PostgreSQL) mostraban jornadas de 10-12 horas.

8.7 Tabla resumen de jurisprudencia sobre fichaje

8.7 Caso avanzado: empresa tecnológica con manipulación sofisticada

Este caso ilustra un nivel de manipulación significativamente más sofisticado que los anteriores (datos anonimizados):

Situación: Startup tecnológica con 30 empleados. CTO despedido tras conflicto con los socios reclama 18 meses de horas extras no pagadas. La empresa presenta los registros de su sistema de fichaje (app propia desarrollada internamente) mostrando jornadas de 8 horas.

Complejidad del caso: Al ser una empresa tecnológica, el CTO tenía conocimientos avanzados y acceso completo al sistema. Pero también lo tenían los socios que lo despidieron, que eran desarrolladores.

Hallazgos del análisis forense:

1. El sistema no tenía hash de integridad (primer hallazgo crítico). A pesar de ser una empresa tecnológica, su sistema propio no implementaba ningún mecanismo criptográfico.

2. Los logs de auditoría estaban activos pero eran editables: El rol de administrador de base de datos tenía permisos UPDATE y DELETE sobre la tabla de logs.

3. Análisis del binary log de PostgreSQL: Al analizar el WAL de PostgreSQL (que la empresa no sabía que se conservaba), encontré 312 operaciones UPDATE ejecutadas en una sola transacción, 5 días después del despido. Todas modificaban fichajes de salida del CTO, cambiándolos de horarios entre las 21:00-23:00 a las 18:00.

4. IP de origen de la transacción: La sesión que ejecutó los 312 UPDATEs se inició desde una IP residencial que, tras consulta al operador (con autorización judicial), correspondía al domicilio del CEO.

5. Repositorio Git como evidencia complementaria: El código fuente de la empresa estaba en GitHub. Los commits del CTO tenían timestamps que mostraban actividad de desarrollo entre las 18:00 y las 23:00 de forma consistente durante 18 meses. Los commits de Git son firmados por el servidor de GitHub con timestamps verificables.

6. Slack corporativo: Los mensajes del CTO en canales de trabajo mostraban actividad continua hasta las 22:00-23:00 la mayoría de los días laborables.

Conclusión del informe: Se demostró con certeza técnica la manipulación de 312 fichajes y se cuantificaron las horas extras con tres fuentes independientes de corroboración (Git, Slack, PostgreSQL WAL). El tribunal condenó a la empresa.

Lección forense: Incluso en empresas tecnológicas con acceso a ingenieros de software, los rastros digitales son enormemente difíciles de eliminar completamente. El WAL de PostgreSQL, los logs de Git y las plataformas de comunicación (Slack, Teams) crean múltiples capas de evidencia que se refuerzan mutuamente.

8.8 Tabla ampliada: resumen de jurisprudencia y casos tipo sobre fichaje

9. El informe pericial de fichaje: estructura y contenido

El informe pericial informático es el documento que sintetiza todo el análisis forense y lo presenta en un formato comprensible para el tribunal. En mi experiencia, la calidad del informe es tan importante como la calidad del análisis: un informe mal estructurado puede desaprovechar un análisis excelente.

Tipos de pericial en el ámbito laboral:

En los procedimientos laborales, lo más frecuente es la pericial de parte: el trabajador (o la empresa) contrata un perito que emite un informe y lo presenta como prueba. El juez valora la pericia conforme a las reglas de la sana crítica (artículo 348 LEC), lo que significa que no está obligado a aceptar las conclusiones del perito, pero si las rechaza, debe motivar por qué.

9.1 Objeto de la pericia

La primera sección del informe define con precisión qué se pide al perito. En el caso de un peritaje de fichaje, el objeto suele ser:

«Determinar si los registros de jornada contenidos en el sistema de fichaje [nombre del sistema] de la empresa [nombre] correspondientes al período [fecha inicio] a [fecha fin] del trabajador [nombre/código] presentan evidencias de manipulación, alteración o falta de integridad que comprometan su valor como prueba digital.»

Errores que evito:

• Definir el objeto de forma ambigua o excesivamente amplia.
• Incluir valoraciones jurídicas (el perito analiza hechos técnicos, no interpreta la ley).
• Aceptar un objeto que no puedo verificar técnicamente con los datos disponibles.

9.2 Metodología (ISO 27037, RFC 3227)

La metodología es la base sobre la que se sustenta la credibilidad del informe. Los estándares que aplico son:

• ISO 27037:2012 — «Directrices para la identificación, recopilación, adquisición y preservación de evidencia digital». Define el marco general del proceso forense.
• RFC 3227 — «Guidelines for Evidence Collection and Archiving». Establece el orden de volatilidad de las evidencias y las prioridades de adquisición.
• UNE 71506:2013 — «Metodología para el análisis forense de las evidencias electrónicas». Norma española específica que complementa la ISO 27037.

En mi informe, documento explícitamente qué estándar aplico y por qué. Esto es fundamental porque la contraparte puede impugnar la metodología, y un perito que no sigue estándares reconocidos es más vulnerable a esta impugnación.

9.3 Adquisición de la evidencia

En esta sección documento:

• Qué se adquirió: Base de datos del sistema de fichaje, logs de auditoría, logs del servidor, backups.
• Cómo se adquirió: Copia forense con herramienta certificada, dump de base de datos, snapshot de servidor.
• Cuándo se adquirió: Fecha, hora y zona horaria exactas.
• Quién estuvo presente: Nombres de las personas que asistieron a la adquisición (representantes de ambas partes, si aplica).
• Hash de la evidencia: SHA-256 de cada archivo o imagen forense obtenida.

9.4 Análisis técnico

Esta es la sección central del informe, donde presento los resultados del análisis aplicando las técnicas descritas en las secciones anteriores:

1. Descripción del sistema de fichaje: Fabricante, versión, base de datos, arquitectura.
2. Verificación de integridad criptográfica: ¿El sistema implementa hash? Resultados de la verificación.
3. Análisis de metadatos: Inconsistencias detectadas en timestamps, IPs, User Agents.
4. Análisis de logs de auditoría: Modificaciones detectadas, gaps en secuencia, operaciones sospechosas.
5. Análisis estadístico: Patrones de regularidad artificial, distribuciones sospechosas.
6. Correlación con fuentes externas: Discrepancias con VPN, email, WiFi, GPS (si están disponibles).
7. Registros eliminados: Resultados de la búsqueda de registros borrados (soft y hard delete).

9.5 Resultados y conclusiones

Las conclusiones deben ser claras, concisas y técnicamente fundamentadas. Evito lenguaje ambiguo y utilizo una escala de certeza:

• Certeza técnica: La manipulación está matemáticamente demostrada (hash no coincide).
• Alta probabilidad: Múltiples indicios convergentes apuntan a la manipulación (metadatos, patrones estadísticos, correlación).
• Indicios significativos: Existen indicios que sugieren manipulación pero no son concluyentes por sí solos.
• No concluyente: Los datos disponibles no permiten determinar si hubo manipulación.

9.6 Cadena de custodia

La cadena de custodia documenta quién ha tenido acceso a la evidencia digital desde su adquisición hasta su presentación en juicio. Incluye:

• Fecha y hora de cada transferencia de la evidencia.
• Identidad de la persona que entrega y la que recibe.
• Hash de verificación en cada transferencia (para confirmar que la evidencia no se ha alterado).
• Condiciones de almacenamiento (medio cifrado, ubicación, control de acceso).

9.7 Estructura tipo del informe pericial de fichaje

La ratificación en juicio:

Un aspecto que muchos clientes desconocen es que el informe pericial, por sí solo, no tiene valor probatorio pleno hasta que el perito lo ratifica y defiende en la vista oral. Durante la ratificación, tanto el abogado de la parte que propuso la prueba como el de la parte contraria pueden formular preguntas al perito.

Las preguntas más habituales que recibo en ratificaciones de peritajes de fichaje:

1. «¿Puede garantizar que nadie más modificó los registros?» — El perito no puede garantizar con certeza absoluta un negativo. Lo que puedo afirmar es qué evidencias encontré y qué nivel de certeza técnica ofrecen.
2. «¿Podría deberse a un error del sistema y no a una manipulación deliberada?» — Para responder esto, analizo si la modificación afecta selectivamente a registros que benefician a una de las partes. Un error de sistema sería aleatorio; una manipulación es selectiva.
3. «¿Qué formación tiene usted para realizar este análisis?» — Es esencial documentar la experiencia y certificaciones del perito en el propio informe.
4. «¿Utilizó la misma metodología que habría utilizado otro perito?» — La adhesión a estándares ISO 27037 y UNE 71506 responde esta pregunta afirmativamente.

Consejos para abogados que trabajan con peritajes de fichaje:

Si eres abogado laboralista y estás considerando solicitar un peritaje de fichaje, ten en cuenta lo siguiente:

• Solicita el peritaje lo antes posible: Cuanto más tiempo pase, más posibilidades hay de que se sobrescriban datos (backups antiguos, logs rotados, espacio libre reutilizado).
• Preserva la evidencia del trabajador: Si tu cliente tiene capturas de pantalla, correos electrónicos o mensajes WhatsApp que contradicen el fichaje oficial, solicita un peritaje de WhatsApp para autenticarlos.
• Solicita acceso amplio: No pidas solo «los registros de fichaje». Pide la base de datos completa, los logs de auditoría, los backups de los últimos 6 meses y los logs del servidor.
• Designa al perito antes de la vista: El perito necesita tiempo para adquirir, analizar y elaborar el informe. Un plazo mínimo razonable es de 3-4 semanas.

10. Carga de la prueba en disputas de jornada laboral

Entender cómo funciona la carga de la prueba en el ámbito laboral es esencial para comprender el papel del peritaje de fichaje. El derecho laboral español aplica reglas específicas que favorecen al trabajador, y el informe pericial puede ser la pieza que active esas reglas.

10.1 Regla general: quien alega, prueba

El principio general del derecho procesal es que la carga de la prueba corresponde a quien alega un hecho (artículo 217 LEC). Si un trabajador reclama horas extras, en principio debería probar que las realizó.

10.2 Excepción laboral: inversión de carga probatoria

Sin embargo, en el ámbito laboral español, opera una excepción consolidada por la jurisprudencia: cuando el trabajador aporta indicios razonables de que realizó horas extras, la carga de la prueba se invierte y es la empresa quien debe demostrar que no las hubo.

¿Qué constituye un «indicio razonable»? La jurisprudencia ha aceptado como indicios:

• Un cuaderno manuscrito del trabajador con sus horas (TSJ Madrid 6489/2024).
• Mensajes de WhatsApp del supervisor fuera de horario pidiendo tareas.
• Testimonios de compañeros de trabajo.
• Correos electrónicos enviados fuera del horario laboral.
• Conexiones VPN fuera de horario.

10.3 Efecto de la ausencia de registro: presunción pro-trabajador

Desde la entrada en vigor del RD-ley 8/2019, la empresa está obligada a registrar la jornada. Si no lo hace, o si su registro es técnicamente infiable, se activa una presunción favorable al trabajador.

Esta presunción significa que:

1. El tribunal presume que las horas extras alegadas por el trabajador son ciertas.
2. La empresa debe aportar prueba en contrario para desvirtuarla.
3. Un sistema de fichaje sin integridad forense puede ser considerado equivalente a la ausencia de registro.

Aquí es donde el peritaje tiene mayor impacto: si demuestro que el sistema de fichaje es técnicamente manipulable (sin hash, sin logs inmutables, sin trazabilidad), el tribunal puede considerar que la empresa no dispone de un registro fiable, activando la presunción pro-trabajador.

El rol de la ITSS en la detección de manipulaciones:

La Inspección de Trabajo y Seguridad Social (ITSS) tiene potestad para verificar el cumplimiento de la obligación de registro de jornada. En la práctica, la ITSS puede:

1. Requerir la presentación de los registros de todos los trabajadores o de trabajadores específicos, para un periodo determinado.
2. Verificar in situ que el sistema funciona correctamente y que los trabajadores efectivamente lo utilizan.
3. Detectar irregularidades como la ausencia total de registro, registros manifiestamente falsos (todos idénticos) o discrepancias con la realidad observada.
4. Levantar acta de infracción si detecta incumplimiento, con sanción que puede alcanzar los 7.500 euros por infracción grave (LISOS art. 7.5).

Sin embargo, la ITSS no realiza peritajes informáticos en sentido estricto. Su labor es inspectora, no pericial. Cuando la ITSS detecta indicios de manipulación sofisticada (no una simple ausencia de registro), lo habitual es que el acta de inspección se convierta en un indicio adicional que el trabajador puede utilizar en un procedimiento judicial posterior, donde sí cabe solicitar un peritaje informático completo.

Datos de la ITSS 2024:

Según la Memoria Anual de la ITSS 2024, en materia de tiempo de trabajo:

• Se realizaron más de 18.000 actuaciones inspectoras relacionadas con el registro de jornada.
• Se detectaron irregularidades en el 34 % de las empresas inspeccionadas.
• Las infracciones más frecuentes fueron: ausencia total de registro (41 %), registro incompleto (28 %) y registro no accesible al trabajador (19 %).
• Solo un 12 % de las infracciones se referían a indicios de manipulación del registro.

Ese 12 % (aproximadamente 2.160 empresas) representa los casos donde la labor del perito informático forense puede ser determinante.

10.4 STS: el trabajador solo necesita «indicios razonables»

El Tribunal Supremo ha reiterado que el estándar probatorio para el trabajador es bajo: solo necesita aportar indicios razonables, no prueba plena. Una vez aportados los indicios, la empresa debe destruirlos con prueba sólida.

El ciclo completo en un caso de peritaje — Desde la perspectiva del trabajador:

1. El trabajador alega horas extras y aporta indicios (WhatsApp, emails, cuaderno personal, registro de llamadas).
2. La empresa aporta su registro de fichaje mostrando jornadas de 8 horas.
3. El trabajador solicita un peritaje del sistema de fichaje.
4. El perito demuestra que el sistema carece de integridad forense y/o detecta manipulaciones.
5. El tribunal considera que el registro no es fiable.
6. La carga de la prueba recae sobre la empresa.
7. Sin un registro fiable, la empresa no puede destruir los indicios del trabajador.
8. Condena al pago de horas extras.

El ciclo completo en un caso de peritaje — Desde la perspectiva de la empresa:

1. Un trabajador despedido reclama horas extras alegando jornadas de 12 horas durante 2 años.
2. La empresa aporta su registro de fichaje con hash SHA-256, logs inmutables y cadena de custodia.
3. El trabajador impugna el registro y solicita un peritaje.
4. El perito verifica los hashes: todos coinciden. Los logs muestran que no hubo modificaciones. Los metadatos son consistentes.
5. El perito certifica la integridad del sistema y la fiabilidad de los registros.
6. El tribunal acepta los registros como prueba sólida.
7. Los indicios del trabajador (que resultaron ser capturas de pantalla de un chat personal no laboral) no son suficientes para contradecir un registro técnicamente verificado.
8. Desestimación de la demanda.

Moraleja: El peritaje informático de fichaje no es inherentemente favorable al trabajador ni a la empresa. Es favorable a la parte que dice la verdad, siempre que cuente con un sistema técnicamente sólido o con evidencia alternativa que la respalde.

10.5 El registro como escudo del empresario

Es importante señalar que un registro de fichaje con integridad forense no solo protege al trabajador: también protege a la empresa frente a reclamaciones infundadas.

Si la empresa utiliza un sistema con hash SHA-256, logs inmutables y cadena de custodia verificable, el perito puede certificar que los registros son íntegros. En ese caso, la empresa tiene una prueba sólida de que las jornadas registradas son las que efectivamente se realizaron.

El registro forense-ready es un activo que protege a ambas partes. La empresa que invierte en un sistema de fichaje con garantías forenses está invirtiendo en tranquilidad jurídica.

10.6 Consecuencias prácticas para empresas y trabajadores

Para la empresa:

La inversión de la carga probatoria tiene consecuencias económicas directas. Si la empresa no puede demostrar la fiabilidad de su sistema de fichaje:

1. Presunción de horas extras: El tribunal presume ciertas las horas alegadas por el trabajador, que puede reclamar hasta 1 año hacia atrás (prescripción).
2. Sanción administrativa: La ITSS puede imponer multas de 751 a 7.500 euros por infracción grave (artículo 7.5 LISOS) por cada trabajador afectado.
3. Cotizaciones a la Seguridad Social: Las horas extras no declaradas generan deuda con la Seguridad Social, con recargos e intereses.
4. Daño reputacional: Las sentencias condenatorias son públicas y pueden afectar la imagen de la empresa.

Para el trabajador:

La carga de la prueba aligerada no significa ausencia total de carga. El trabajador debe:

1. Aportar al menos indicios razonables (no basta una mera alegación verbal sin soporte alguno).
2. Preservar la evidencia propia: no borrar mensajes de WhatsApp, guardar correos electrónicos, anotar las horas reales.
3. Actuar con diligencia temporal: las horas extras prescriben al año (artículo 59.1 ET). Reclamar a los 2 años implica perder el primer año.

Recomendación práctica para trabajadores:

Si sospechas que tu empresa manipula los registros de fichaje, las acciones inmediatas más efectivas son:

1. Lleva tu propio registro diario: Anota la hora real de entrada y salida cada día. Un cuaderno manuscrito tiene valor probatorio reconocido (TSJ Madrid 6489/2024).
2. Envíate un email a ti mismo al llegar y al salir: El timestamp del servidor de correo es una evidencia independiente.
3. No borres mensajes de trabajo fuera de horario: WhatsApp, Teams, Slack… todos son evidencia potencial.
4. Consulta con un abogado laboralista antes de actuar: La estrategia procesal importa tanto como la evidencia técnica.

11. Manipulaciones más frecuentes y cómo detectarlas

Tras años realizando peritajes de fichaje, he identificado patrones recurrentes de manipulación. Estas son las manipulaciones que encuentro con mayor frecuencia y las técnicas específicas que utilizo para detectarlas.

11.1 Modificación de hora de salida (la más común)

Es, con diferencia, la manipulación más extendida. La empresa modifica la hora de salida para que coincida con el horario contractual, eliminando las horas extras reales.

Cómo se ejecuta:

• El administrador accede al panel de gestión y cambia la hora de salida (por ejemplo, de 20:30 a 18:00).
• O bien, el administrador accede directamente a la base de datos y ejecuta un UPDATE.

Cómo la detecto:

1. Hash comprometido: Si el sistema tiene hash, la modificación se detecta instantáneamente.
2. updated_at ≠ created_at: Si la base de datos tiene timestamp de modificación, este será posterior al de creación.
3. Log de auditoría: Si existe y es inmutable, registrará la operación UPDATE.
4. Correlación: Si el trabajador envió un email a las 20:15 (después de la supuesta salida a las 18:00), hay una discrepancia.
5. Análisis estadístico: Si todos los fichajes de salida son a las 18:00:00 exactas, la uniformidad es sospechosa.

11.2 Eliminación de fichajes de fin de semana

Cuando un trabajador ficha en fin de semana (probando trabajo no remunerado), la empresa puede eliminar esos registros para evitar la evidencia de horas extras.

Cómo la detecto:

1. Gaps en la secuencia de IDs: Si los fichajes del viernes tienen ID 1000 y los del lunes tienen ID 1005, faltan 4 registros.
2. Registros en espacio libre: Con herramientas de recuperación de datos, puedo buscar fichajes eliminados en el espacio libre de la base de datos.
3. Logs del sistema: Incluso si los fichajes fueron borrados, el log del sistema operativo del servidor puede registrar la conexión del terminal de fichaje durante el fin de semana.
4. WiFi corporativo: Si el trabajador conectó su dispositivo al WiFi de la oficina el sábado, hay evidencia independiente.

11.3 Creación retroactiva de registros masivos

Algunas empresas, ante una inspección o demanda, crean registros de fichaje retroactivamente. Generan semanas o meses de fichajes falsos en un solo día.

Cómo la detecto:

1. Timestamps de creación agrupados: Si 200 registros de 6 meses diferentes fueron creados todos el mismo día a la misma hora, la manipulación es obvia.
2. IDs de transacción consecutivos: 200 registros con IDs secuenciales que se insertan en un rango temporal de minutos, cuando deberían distribuirse en 6 meses.
3. Uniformidad extrema: Los datos fabricados tienden a ser demasiado perfectos (siempre 8 horas exactas, sin variación).
4. Sin variación de IP/dispositivo: Si todos los registros provienen de la misma IP y dispositivo, fueron creados desde el mismo puesto.
5. Ausencia de datos contextuales: Los registros fabricados suelen carecer de geolocalización, User Agent variado u otros metadatos que un fichaje real generaría.

11.4 Buddy punching (compañero que ficha por otro)

El buddy punching ocurre cuando un trabajador ficha por un compañero ausente. Es más difícil de detectar porque genera un fichaje «real» desde un terminal legítimo.

Cómo la detecto:

1. Análisis temporal: Si dos trabajadores fichan siempre con diferencia de segundos (por ejemplo, empleado A ficha a las 08:59:45 y empleado B a las 08:59:47), es sospechoso.
2. Mismo terminal, misma ventana: Dos fichajes desde el mismo terminal en menos de 10 segundos implican que la misma persona ficó ambas tarjetas.
3. Correlación con otros datos: Si el trabajador B fichó su entrada pero no tiene actividad de email, VPN ni WiFi durante toda la jornada, probablemente no estaba presente.
4. Cámaras de seguridad: Si están disponibles, las grabaciones del terminal de fichaje son prueba directa.

11.5 Admin override sin justificación

Los administradores del sistema tienen capacidad para corregir fichajes (por errores legítimos). El problema surge cuando estas correcciones se realizan sin justificación documentada y sin control.

Cómo la detecto:

1. Proporción de correcciones: Si el 30 % de los fichajes han sido «corregidos» por el administrador, la proporción es anormal.
2. Correcciones selectivas: Si las correcciones afectan siempre a las horas de salida (nunca a las de entrada) o siempre reducen la jornada (nunca la amplían), el patrón es sospechoso.
3. Correcciones masivas en fecha concreta: Un pico de correcciones administrativas justo antes de una inspección o demanda es altamente sospechoso.
4. Ausencia de motivos: Si el sistema no exige un motivo para cada corrección, o si los motivos son genéricos («error del sistema»), la trazabilidad es insuficiente.

11.6 Tabla: señales de alerta y método de detección

11.7 Redondeo sistemático de jornada

Algunos sistemas de fichaje incluyen una función de «redondeo» que ajusta automáticamente los fichajes al intervalo más cercano (por ejemplo, 15 minutos). Si un trabajador ficha a las 18:23, el sistema registra 18:15 o 18:30. Este redondeo, cuando se aplica siempre en la dirección que favorece a la empresa (redondeando la entrada hacia atrás y la salida hacia delante… o al revés), puede generar un robo de tiempo acumulado significativo.

Cómo lo detecto:

1. Comparación de datos brutos vs redondeados: Si el sistema almacena tanto el fichaje original como el redondeado, la comparación revela el sesgo.
2. Análisis de la dirección del redondeo: Si el 90 % de los redondeos de entrada acortan la jornada y el 90 % de los de salida también, hay sesgo sistemático.
3. Cuantificación del impacto: Calculo las horas acumuladas perdidas por el trabajador debido al redondeo. En jornadas largas, 15 minutos diarios de redondeo adverso equivalen a más de 65 horas anuales (más de 8 jornadas completas).

11.8 Cambio de zona horaria en el servidor

Una manipulación sofisticada que he encontrado en un par de ocasiones: el administrador cambia la zona horaria del servidor justo antes del horario de cierre, de modo que los timestamps se desplazan. Por ejemplo, si el servidor cambia de CET (UTC+1) a UTC a las 17:30, un fichaje real a las 18:30 CET se registra como 17:30 UTC, aparentando una salida una hora antes.

Cómo lo detecto:

1. Logs del sistema operativo: Los cambios de zona horaria quedan registrados en los logs del sistema operativo (syslog en Linux, Event Log en Windows).
2. Inconsistencia con otras fuentes: Si los emails del servidor de correo (que tiene su propia zona horaria) muestran una hora y los fichajes muestran otra, hay una discrepancia que investigar.
3. Timestamps UTC internos: Muchos sistemas de bases de datos almacenan internamente los timestamps en UTC, independientemente de la zona horaria configurada. La comparación del UTC almacenado con el mostrado puede revelar cambios de zona horaria.

11.9 Uso de cuentas genéricas para modificaciones

En lugar de utilizar su cuenta personal de administrador (que quedaría registrada en los logs), algunos administradores crean o utilizan cuentas genéricas («admin», «sistema», «soporte») para realizar modificaciones. Esto dificulta la atribución personal de la manipulación.

Cómo lo detecto:

1. Auditoría de cuentas: Identifico todas las cuentas con privilegios de administración y verifico cuáles son nominativas y cuáles genéricas.
2. Patrones de uso: Una cuenta genérica utilizada siempre desde la misma IP y en los mismos horarios probablemente corresponde a una persona concreta.
3. Correlación temporal: Si las modificaciones realizadas con la cuenta genérica coinciden en horario con la presencia de un directivo concreto (según el control de acceso físico), la atribución se refuerza.

12. Herramientas forenses para análisis de fichaje

El análisis forense de registros de fichaje requiere un conjunto específico de herramientas. A continuación, detallo las herramientas que utilizo según el tipo de sistema y análisis.

12.1 SQLite y PostgreSQL forensics

La mayoría de los sistemas de fichaje almacenan sus datos en bases de datos relacionales. Las herramientas específicas para cada motor son:

SQLite (común en apps móviles y sistemas embebidos):

• DB Browser for SQLite: Interfaz gráfica para explorar la estructura y datos de bases SQLite.
• sqlite3 (CLI): Herramienta de línea de comandos para consultas y exportaciones.
• undark: Herramienta especializada en la recuperación de registros eliminados en bases SQLite. Analiza las páginas libres (freepages) del archivo de base de datos.
• sqlite3_analyzer: Proporciona estadísticas detalladas sobre el uso de espacio en la base de datos, incluyendo páginas libres que pueden contener datos eliminados.

PostgreSQL (común en sistemas empresariales):

• pg_dump / pg_dumpall: Para la adquisición forense de la base de datos completa.
• pgAdmin: Interfaz gráfica para exploración y consultas.
• pg_xlogdump / pg_waldump: Análisis del Write-Ahead Log para recuperar operaciones pasadas.
• Barman: Para gestión y análisis de backups, útil para comparar estados de la base de datos en diferentes momentos.

MySQL / MariaDB:

• mysqlbinlog: Análisis del binary log para recuperar todas las operaciones DML ejecutadas.
• MySQL Workbench: Interfaz gráfica para exploración.
• Percona Toolkit: Conjunto de herramientas que incluye pt-table-checksum para verificación de integridad.

12.2 Herramientas de análisis de metadatos

• ExifTool: Extracción de metadatos de cualquier tipo de archivo (Excel, PDF, imágenes).
• oletools: Suite Python para análisis de archivos OLE2 (Excel .xls, Word .doc).
• python-pptx / openpyxl: Librerías Python para análisis programático de archivos Excel .xlsx.
• Autopsy / The Sleuth Kit: Plataforma forense completa que incluye análisis de metadatos del sistema de archivos.

12.3 Scripts de verificación de hash

Para la verificación de integridad criptográfica, desarrollo scripts personalizados adaptados a la estructura de cada sistema de fichaje. El proceso típico es:

1. Extraer la estructura de hash: Identificar qué campos incluye el sistema en el cálculo del hash y en qué orden.
2. Desarrollar el script de verificación: Un script que recorre todos los registros, recalcula el hash y compara con el almacenado.
3. Documentar el script: El script se incluye como anexo del informe pericial para que la contraparte pueda reproducir la verificación.

Herramientas y lenguajes utilizados:

• Python + hashlib: Mi herramienta principal para scripts de verificación. La librería hashlib soporta MD5, SHA-1, SHA-256, SHA-512 y otros.
• OpenSSL (CLI): Para verificaciones rápidas desde línea de comandos.
• CertUtil (Windows): Alternativa en entornos Windows.

12.4 Análisis de logs con ELK Stack

Cuando el volumen de logs es elevado (miles o millones de entradas), utilizo el stack ELK (Elasticsearch, Logstash, Kibana) para su análisis:

• Logstash: Ingesta y parseo de los logs en un formato estructurado.
• Elasticsearch: Indexación y búsqueda rápida de eventos específicos.
• Kibana: Visualización de patrones temporales, detección de anomalías, dashboards interactivos.

La principal ventaja de ELK es la capacidad de visualizar patrones que serían invisibles en una revisión manual. Un dashboard de Kibana puede mostrar instantáneamente picos de actividad administrativa en fechas sospechosas o gaps en la secuencia de logs.

12.5 Herramientas de timeline (correlación temporal)

La correlación temporal es una de las técnicas más poderosas del análisis forense. Las herramientas de timeline permiten alinear cronológicamente eventos de múltiples fuentes:

• log2timeline / plaso: Herramienta de referencia para la creación de supertimellines. Puede procesar logs de diferentes formatos y alinearlos en una línea temporal única.
• TimeSketch: Interfaz web para exploración colaborativa de timelines forenses. Desarrollada por Google.
• Excel / LibreOffice Calc: Para casos con volumen manejable, una hoja de cálculo con los eventos de todas las fuentes ordenados cronológicamente sigue siendo efectiva.
• Python + pandas: Para análisis programático de correlación temporal entre datasets.

12.6 Herramientas de análisis estadístico

Para la detección de patrones artificiales descritos en la sección 3.6, utilizo:

• Python + scipy.stats: Tests estadísticos como chi-cuadrado para verificar si la distribución de los segundos sigue un patrón uniforme o si hay concentración artificial en valores redondos (:00, :15, :30, :45).
• Python + matplotlib / seaborn: Generación de histogramas y heatmaps que visualizan la distribución temporal de los fichajes. Estos gráficos se incluyen como anexos del informe pericial.
• R + ggplot2: Alternativa para análisis estadísticos avanzados y generación de gráficos de calidad publicación.
• Test de Benford (first-digit test): Implementación en Python para verificar si los primeros dígitos de los minutos de fichaje siguen la distribución esperada según la ley de Benford.

Ejemplo de output que incluyo en mis informes:

Un heatmap que muestra la distribución de fichajes por día de la semana y hora del día puede revelar patrones invisibles a simple vista. Si todos los fichajes de un trabajador se concentran exactamente en las mismas horas durante 12 meses sin variación alguna, el gráfico muestra una línea perfecta que contrasta con la nube de puntos irregular que produciría un patrón de fichaje real.

12.7 Detección de técnicas anti-forenses

En algunos casos, el administrador del sistema no solo manipula los registros, sino que también intenta cubrir sus huellas. Las técnicas anti-forenses más comunes que encuentro en peritajes de fichaje son:

Truncado de logs:

El administrador no elimina entradas individuales del log (lo que dejaría gaps en la secuencia), sino que trunca el log completo, eliminando todas las entradas anteriores a una fecha determinada. Esto es detectable porque:

• El ID mínimo del log no es 1 (indica que se eliminaron las entradas anteriores).
• La fecha de la primera entrada del log no coincide con la fecha de instalación del sistema.
• Los backups anteriores al truncado (si existen) contendrán las entradas eliminadas.

Reinstalación del sistema:

En casos extremos, he encontrado empresas que reinstalan el sistema de fichaje desde cero, perdiendo todos los datos históricos. Esto es detectable a través de:

• La fecha de instalación del software (metadatos del sistema de archivos).
• Los backups automáticos del proveedor cloud (si el sistema es SaaS).
• Los registros de licencia del fabricante.

Manipulación del reloj del sistema:

Cambiar la hora del servidor antes de crear registros retroactivos, de modo que los timestamps de creación coincidan con las fechas declaradas. Es detectable mediante:

• Logs del servicio NTP (Network Time Protocol) que registran sincronizaciones de hora.
• Discrepancias con servicios externos que también registran timestamps (proveedores de email, servicios cloud, APIs de terceros).
• Gaps en los logs del sistema operativo que coinciden con los periodos de reloj manipulado.

13. Requisitos de un sistema de fichaje forense-ready

Tras analizar decenas de sistemas de fichaje en el contexto de disputas laborales, he identificado los requisitos técnicos que separan un sistema con garantías forenses de uno sin ellas.

13.1 Los 10 requisitos que un perito busca

Cuando evalúo un sistema de fichaje —ya sea en el contexto de un peritaje, una auditoría preventiva o una consultoría—, verifico estos 10 requisitos:

Si un sistema cumple los 10 requisitos, el perito puede certificar su fiabilidad y los registros tienen pleno valor probatorio. Si falla en los requisitos críticos (1, 3, 6), el sistema no ofrece garantías forenses, independientemente de las demás características.

13.2 Certificaciones y estándares aplicables

Los estándares más relevantes para sistemas de fichaje con orientación forense son:

• ISO 27037: Define los principios para la gestión de evidencia digital. Un sistema de fichaje diseñado conforme a esta norma facilita enormemente el trabajo del perito.
• ENS (Esquema Nacional de Seguridad): Para empresas del sector público o que trabajan con la administración, el ENS establece requisitos de seguridad que incluyen la trazabilidad y la integridad de los datos.
• ISO 27001: El estándar general de seguridad de la información. Su certificación implica controles de integridad, trazabilidad y gestión de logs.
• SOC 2 Type II: Para servicios cloud, certifica que los controles de seguridad se implementan y operan de forma efectiva durante un período.

13.3 Daltico Equipo: diseñado con mentalidad forense

De entre los sistemas de fichaje disponibles en el mercado español, Daltico Equipo destaca por haber sido diseñado desde su concepción con una orientación forense. Analizo sus características técnicas desde la perspectiva de los 10 requisitos que un perito busca:

Integridad criptográfica:

• Hash SHA-256 por cada registro de entrada y salida. Cada fichaje se firma en el momento de su creación, y el hash se almacena junto al registro.
• Encadenamiento de hashes: Los hashes se encadenan secuencialmente, de modo que la manipulación de un registro invalida toda la cadena posterior.
• Verificación independiente: Cualquier perito puede recalcular los hashes y verificar la integridad de los registros sin depender del sistema propietario.

Auditoría y trazabilidad:

• Logs INSERT-only: El log de auditoría se implementa como una tabla de solo inserción. Ningún usuario, incluido el administrador del sistema, puede modificar ni eliminar entradas del log.
• Workflow de corrección obligatorio: Si un responsable necesita corregir un fichaje (por ejemplo, un empleado que olvidó fichar la salida), el sistema exige: (a) una solicitud de corrección con motivo justificado, (b) la aprobación de un responsable diferente del solicitante, (c) la conservación del registro original intacto, con la corrección vinculada como registro adicional.
• Trazabilidad completa: Cada operación (fichaje, consulta, corrección, exportación) queda registrada con usuario, timestamp, IP y dispositivo.

Contexto evidencial:

• Captura de IP, dispositivo y geolocalización en cada fichaje. Estos metadatos son fundamentales para la correlación forense.
• Timestamp del servidor: La hora del fichaje la genera el servidor (no el dispositivo del empleado), eliminando la posibilidad de manipulación de hora.
• Integración WhatsApp con log separado: La comunicación laboral por WhatsApp se registra de forma independiente, creando una fuente adicional de evidencia.

Generación de reportes:

• PDFs con cadena de custodia: El sistema genera reportes en PDF que incluyen el hash del propio documento, permitiendo verificar que el reporte no ha sido alterado después de su generación.
• Modo inspección ITSS: Un modo específico para inspectores de trabajo que permite la exportación certificada de registros sin alterar los datos originales.

13.4 Comparativa: fichaje genérico vs fichaje forense

13.5 Checklist de evaluación rápida para empresas

Si eres responsable de RRHH, dirección o asesoría jurídica de una empresa y quieres evaluar rápidamente si tu sistema de fichaje ofrece garantías forenses, responde a estas 10 preguntas:

1. ¿Tu sistema genera un hash SHA-256 (o equivalente) por cada registro de fichaje? Sí / No
2. ¿Los hashes están encadenados (el hash de cada registro incorpora el anterior)? Sí / No
3. ¿El log de auditoría es inmutable (solo INSERT, sin UPDATE ni DELETE)? Sí / No
4. ¿Las correcciones de fichaje requieren solicitud, aprobación y motivo documentado? Sí / No
5. ¿Se captura IP, dispositivo y geolocalización en cada fichaje? Sí / No
6. ¿El timestamp lo genera el servidor (no el dispositivo del empleado)? Sí / No
7. ¿El sistema puede generar informes PDF con hash del documento incluido? Sí / No
8. ¿Existe segregación de roles (el admin no puede modificar registros sin auditoría)? Sí / No
9. ¿Hay un modo de exportación certificada para inspecciones de trabajo? Sí / No
10. ¿Los datos se conservan al menos 4 años? Sí / No

Resultados:

Si tu resultado es 5 o inferior, te recomiendo encarecidamente evaluar alternativas con integridad forense como Daltico Equipo antes de que surja un conflicto laboral.

13.6 Guía de implementación para departamentos de TI

Si tu empresa decide migrar a un sistema de fichaje con garantías forenses, estas son las consideraciones técnicas clave para el equipo de TI:

Antes de la migración:

1. Exportar todos los datos del sistema actual con cadena de custodia documentada. Calcular hash SHA-256 de la exportación.
2. Conservar el sistema antiguo en modo solo lectura durante al menos 2 años (por si se necesita para litigios en curso).
3. Documentar la fecha exacta del cambio y comunicar a los representantes de los trabajadores.

Durante la configuración:

1. Configurar los roles de usuario: Separar administradores de sistema (TI) de administradores funcionales (RRHH). Ningún usuario debería tener permisos de escritura directa sobre la tabla de fichajes.
2. Activar todos los logs de auditoría al nivel máximo desde el primer día.
3. Configurar backups automáticos con verificación de integridad y retención de al menos 4 años.
4. Establecer el workflow de correcciones: Definir quién puede solicitar correcciones, quién las aprueba y qué motivos son aceptables.

Verificación post-implementación:

1. Test de integridad: Realizar un fichaje de prueba, verificar que el hash se genera correctamente y que es recalculable de forma independiente.
2. Test de auditoría: Realizar una corrección de prueba y verificar que el log registra todos los pasos (solicitud, aprobación, ejecución).
3. Test de inmutabilidad: Intentar modificar directamente un registro en la base de datos y verificar que: (a) no es posible, o (b) el hash se invalida y el log lo registra.
4. Test de exportación: Generar un reporte PDF y verificar que incluye hash del documento.

14. Preguntas frecuentes

¿Puede un perito informático acceder a cualquier sistema de fichaje?

El perito informático puede acceder al sistema de fichaje cuando existe una resolución judicial que así lo ordene (pericial judicial) o cuando la empresa colabora voluntariamente (pericial de parte o extrajudicial). En procedimientos judiciales, el juez puede requerir a la empresa que facilite acceso al sistema, a la base de datos y a los logs. Si la empresa se niega a cumplir un requerimiento judicial, el tribunal puede aplicar la ficta confessio (considerar ciertos los hechos que la prueba pretendía demostrar).

¿Cuánto cuesta un peritaje de registros de fichaje?

El coste depende de la complejidad del sistema, el volumen de datos a analizar y el alcance del encargo. Como referencia orientativa:

¿Qué plazo tiene la empresa para facilitar los registros de fichaje?

El artículo 34.9 del Estatuto de los Trabajadores establece que la empresa debe conservar los registros de jornada durante 4 años y tenerlos «a disposición de las personas trabajadoras, de sus representantes legales y de la Inspección de Trabajo y Seguridad Social». Si se solicitan en el marco de un procedimiento judicial, el plazo lo fija el juez en el requerimiento.

¿Es válido un fichaje por WhatsApp?

Enviar un mensaje de WhatsApp diciendo «ya estoy en la oficina» no constituye, por sí solo, un sistema de registro de jornada conforme al artículo 34.9 ET. Sin embargo, los mensajes de WhatsApp pueden ser prueba complementaria de la jornada real. Si un trabajador envía mensajes laborales a las 22:00, esos mensajes son evidencia de actividad laboral fuera del horario registrado. El peritaje forense de WhatsApp puede autenticar estos mensajes para su presentación en juicio.

¿Puede el empleador modificar registros de fichaje?

Técnicamente, depende del sistema. En muchos sistemas, el administrador tiene permisos para modificar cualquier registro. Jurídicamente, modificar registros de fichaje para ocultar horas extras constituye una falsedad documental que puede tener consecuencias laborales (despido nulo por vulneración de derechos) y penales (artículo 390 del Código Penal, falsedad en documento privado). Desde la perspectiva forense, la cuestión no es si puede, sino si la modificación es detectable: con hash SHA-256, la respuesta es siempre sí.

¿Qué pasa si el sistema de fichaje no tiene logs de auditoría?

La ausencia de logs de auditoría es, en sí misma, un hallazgo significativo que documento en mi informe pericial. Implica que:

1. No se puede rastrear quién modificó qué registros ni cuándo.
2. El sistema no cumple con el estándar de «fiable» exigido por el TS (STS 1161/2024).
3. La empresa no puede demostrar que los registros no fueron manipulados.
4. El tribunal puede considerar que el registro carece de valor probatorio.

¿Sirve una captura de pantalla del fichaje como prueba?

Una captura de pantalla del sistema de fichaje tiene un valor probatorio muy limitado. Es trivialmente falsificable (editar HTML en el navegador, manipular la imagen con herramientas gráficas) y no contiene los metadatos necesarios para verificar su autenticidad. Un tribunal puede admitirla como indicio, pero si es impugnada, difícilmente resistirá un análisis pericial. Lo recomendable es solicitar una exportación directa de la base de datos con cadena de custodia documentada.

¿Quién paga el peritaje en un juicio laboral?

En la jurisdicción social española, la regla general es que cada parte asume el coste de sus propias pruebas periciales. Sin embargo, si la parte que solicita el peritaje tiene reconocido el beneficio de justicia gratuita, puede solicitar un perito designado judicialmente cuyo coste asume la administración. Además, si la sentencia condena en costas a la parte contraria, el coste del peritaje puede incluirse en la tasación de costas.

¿Puede una inspección de trabajo solicitar un peritaje informático?

La ITSS puede requerir a la empresa la presentación de los registros de jornada y, si detecta indicios de manipulación, puede incorporar esta circunstancia al acta de infracción. Aunque la ITSS no suele encargar peritajes informáticos como tales, sus actuaciones pueden dar lugar a procedimientos judiciales donde el peritaje sea relevante. Además, la ITSS puede recabar el auxilio de expertos cuando lo considere necesario.

¿Qué ocurre si el trabajador manipula su propio fichaje?

La manipulación del fichaje por parte del trabajador (por ejemplo, fichar y ausentarse) constituye un incumplimiento contractual grave que puede justificar el despido disciplinario (artículo 54.2.d ET: transgresión de la buena fe contractual). Si se detecta mediante peritaje, el informe documenta la manipulación con el mismo rigor técnico que si se tratara de una manipulación empresarial.

¿Es legal el fichaje biométrico (huella dactilar, reconocimiento facial)?

Tras la sentencia del TJUE de 2023 y las resoluciones de la AEPD, el fichaje biométrico está sujeto a restricciones estrictas. Los datos biométricos se consideran de categoría especial (artículo 9 RGPD) y su tratamiento requiere una base jurídica reforzada. La AEPD ha sancionado a empresas que implementaron fichaje por huella dactilar sin realizar una evaluación de impacto (DPIA) previa ni demostrar que no existían alternativas menos intrusivas. Como perito, analizo si el tratamiento biométrico cumple con el RGPD como parte del peritaje.

¿Cuánto tiempo tarda un peritaje de fichaje?

El plazo depende de la complejidad, pero como referencia:

En casos urgentes (medidas cautelares, vistas próximas), puedo acelerar el proceso a 5-7 días.

¿Qué diferencia hay entre un peritaje preventivo y uno judicial?

El peritaje preventivo (o auditoría forense) se realiza antes de que haya conflicto. La empresa contrata al perito para evaluar la robustez de su sistema de fichaje e identificar vulnerabilidades. El resultado es un informe de recomendaciones técnicas.

El peritaje judicial se realiza en el contexto de un procedimiento judicial ya iniciado. El perito analiza los registros concretos en disputa y emite un informe que se presenta como prueba pericial. Este informe debe cumplir requisitos formales específicos (artículos 335-352 LEC) y el perito puede ser llamado a ratificarlo en la vista oral.

¿Puede el comité de empresa solicitar acceso al sistema de fichaje?

Sí. El artículo 34.9 ET establece que los registros deben estar a disposición de los representantes legales de los trabajadores. Esto incluye el acceso a los datos de fichaje de los trabajadores representados. Si la empresa se niega, el comité puede solicitar al juez que ordene el acceso y, en ese contexto, solicitar un peritaje del sistema.

¿El perito puede determinar quién manipuló los registros?

Depende del sistema y de los datos disponibles. Si existen logs de auditoría con identificación de usuario, IP y timestamp, el perito puede identificar la cuenta de usuario que ejecutó la manipulación y la IP desde la que se realizó. Sin embargo, identificar a la persona física detrás de esa cuenta requiere evidencia adicional (por ejemplo, que la IP corresponda al domicilio de un directivo concreto o que las cámaras de seguridad muestren quién estaba en el puesto en ese momento).

¿Qué validez tiene un fichaje realizado desde un dispositivo personal (BYOD)?

El fichaje desde dispositivo personal plantea cuestiones tanto técnicas como de privacidad. Técnicamente, el dispositivo personal es menos controlable que uno corporativo (el empleado puede tener apps de spoofing GPS, por ejemplo). En cuanto a privacidad, la empresa no puede exigir instalar software invasivo en un dispositivo personal sin base jurídica adecuada. Desde la perspectiva forense, el fichaje BYOD es menos fiable que el fichaje desde terminal corporativo o dispositivo gestionado.

¿Qué ocurre si la empresa cambia de sistema de fichaje durante el periodo en disputa?

Es una situación más frecuente de lo que parece. Cuando la empresa migra de un sistema a otro (por ejemplo, de Excel a una app de fichaje) durante el periodo que se analiza, el perito debe:

1. Analizar ambos sistemas de forma independiente.
2. Verificar la migración de datos: ¿se importaron los datos del sistema antiguo al nuevo? ¿Se alteraron durante la importación?
3. Documentar el gap temporal (si existe) entre el cierre del sistema antiguo y la puesta en marcha del nuevo.
4. Evaluar si la empresa conserva los datos del sistema antiguo o si los destruyó.

La destrucción de los datos del sistema antiguo justo después de una migración, especialmente si coincide con un periodo de conflicto laboral, es una señal de alerta significativa.

¿Puede un trabajador solicitar un peritaje por su cuenta antes de ir a juicio?

Sí. Un trabajador puede contratar un perito informático de parte para analizar la evidencia a la que tenga acceso (sus propios correos electrónicos, mensajes WhatsApp, capturas de pantalla, conexiones VPN). Este informe pericial de parte se presenta junto con la demanda laboral. El coste de un peritaje de parte es generalmente inferior al de un peritaje judicial porque el alcance es más limitado (el perito solo analiza la evidencia proporcionada por el cliente, no el sistema completo de la empresa).

¿Qué marco legal protege al trabajador que denuncia la manipulación del fichaje?

El trabajador que denuncia la manipulación del registro de jornada está protegido por la garantía de indemnidad (artículo 24 CE y doctrina constitucional consolidada). Esto significa que la empresa no puede tomar represalias contra el trabajador por ejercer acciones legales o denunciar irregularidades. Si la empresa despide al trabajador tras la denuncia, el despido se presume nulo (no improcedente), con derecho a readmisión obligatoria y salarios de tramitación.

¿Es necesario solicitar un contrainforme si la empresa presenta un peritaje favorable?

Es altamente recomendable. Si la empresa presenta un informe pericial que concluye que su sistema de fichaje es fiable, el trabajador (a través de su abogado) debería solicitar un contrainforme pericial que evalúe críticamente la metodología y conclusiones del perito de la empresa. Un contrainforme eficaz puede identificar:

• Omisiones en el análisis del perito de la empresa (por ejemplo, no verificó los hashes o no analizó los logs).
• Errores metodológicos (no siguió ISO 27037, no documentó la cadena de custodia).
• Conclusiones que no se sostienen con los datos presentados.

Para más información sobre cómo funciona un contrainforme, consulta nuestra guía sobre contrainformes periciales informáticos.

¿Qué sectores tienen más litigiosidad por manipulación de fichaje?

Según mi experiencia profesional y los datos de la ITSS:

¿Cómo afecta el teletrabajo al peritaje de fichaje?

El teletrabajo ha complicado significativamente el análisis forense de fichajes porque:

1. Múltiples ubicaciones: El trabajador puede fichar desde casa, un coworking o un café. La verificación de presencia es más compleja que en una oficina.
2. Dispositivos personales: Si el trabajador usa su propio ordenador, el perito tiene acceso limitado a los datos del dispositivo.
3. Dependencia de VPN: Los logs de VPN se convierten en la fuente principal de evidencia, pero no todos los sistemas de teletrabajo usan VPN.
4. Herramientas de colaboración como fuente de evidencia: Los timestamps de actividad en Slack, Microsoft Teams, Google Workspace o similares pueden complementar o contradecir los registros de fichaje.
5. Software de monitorización: Algunas empresas instalan software que captura screenshots periódicos o registra la actividad del teclado y ratón. Estos datos son evidencia adicional, pero plantean cuestiones serias de privacidad (AEPD).

La Ley de Trabajo a Distancia (Ley 10/2021) refuerza la obligación de registrar la jornada también en modalidad de teletrabajo, pero no especifica los medios técnicos, dejando la misma brecha que el RD-ley 8/2019.

¿Puede la empresa negarse a entregar la base de datos del sistema de fichaje?

En el contexto de un procedimiento judicial, si el juez requiere la entrega de la base de datos del sistema de fichaje, la empresa está obligada a cumplir el requerimiento. La negativa a cumplir un requerimiento judicial puede tener tres consecuencias:

1. Ficta confessio: El tribunal puede considerar ciertos los hechos que la prueba pretendía demostrar (artículo 329 LEC). Es decir, si el trabajador pretendía demostrar horas extras y la empresa se niega a entregar los datos, el tribunal puede presumir que las horas extras son ciertas.
2. Multas coercitivas: El tribunal puede imponer multas coercitivas a la empresa hasta que cumpla el requerimiento.
3. Deducción de responsabilidades penales: En casos graves, la desobediencia al requerimiento judicial puede constituir un delito de desobediencia (artículo 556 CP).

En la práctica, la empresa suele entregar los datos pero en un formato que dificulta el análisis (por ejemplo, un PDF con miles de páginas en lugar de la base de datos exportada). En estos casos, solicito al juez que especifique el formato de entrega: dump de base de datos en formato nativo (PostgreSQL dump, MySQL dump, copia del archivo SQLite) incluyendo tablas de auditoría y logs del servidor.

¿Qué sucede si el sistema de fichaje ya no existe (la empresa cambió de sistema)?

Es un escenario que plantea desafíos significativos. Si la empresa migró a un nuevo sistema y no conservó los datos del sistema anterior:

1. Obligación de conservación: El artículo 34.9 ET obliga a conservar los registros durante 4 años. La destrucción de registros antes de ese plazo puede constituir infracción grave.
2. Backups del proveedor anterior: Si el sistema era SaaS, el proveedor puede conservar copias de los datos incluso después de la baja del servicio (según sus políticas de retención).
3. Backups de la empresa: Si la empresa realizaba backups periódicos de sus sistemas, los datos del sistema de fichaje anterior pueden estar incluidos.
4. Presunción adversa: La destrucción de evidencia relevante puede generar una presunción adversa contra la empresa (doctrina del «spoliation of evidence»).

¿Cómo proteger el registro de fichaje ante un posible litigio futuro?

Tanto la empresa como el trabajador pueden tomar medidas preventivas:

Para la empresa:

• Utilizar un sistema con hash SHA-256, logs inmutables y cadena de custodia.
• Realizar backups verificados periódicamente.
• Implementar una política de retención de datos de al menos 4 años.
• Realizar auditorías preventivas del sistema de fichaje cada 1-2 años.

Para el trabajador:

• Llevar un registro personal diario de entrada y salida.
• Conservar mensajes de WhatsApp, emails y llamadas que evidencien trabajo fuera de horario.
• Solicitar periódicamente una copia de sus registros de fichaje (derecho reconocido en el artículo 34.9 ET).
• Si detecta irregularidades, documentarlas (capturas de pantalla con fecha) y consultar con un abogado laboralista.

15. Referencias y fuentes

1. Sentencia del Tribunal Supremo 1161/2024, de 24 de septiembre de 2024. Sala de lo Social. Requisitos de fiabilidad, trazabilidad y objetividad del sistema de registro de jornada. ECLI:ES:TS:2024:1161.

2. Sentencia del Tribunal Supremo 410/2024, de 5 de marzo de 2024. Sala de lo Social. El registro de jornada no puede utilizarse para modificar unilateralmente condiciones laborales.

3. STJUE de 14 de mayo de 2019, asunto C-55/18 (Federación de Servicios de CC.OO. contra Deutsche Bank SAE). Sistema «objetivo, fiable y accesible» de registro de jornada.

4. Sentencia del TSJ de Madrid, rec. 6489/2024. El cuaderno manuscrito del trabajador como indicio razonable que invierte la carga de la prueba.

5. Sentencias del TSJ de Cataluña (múltiples). Presunción de horas extras a favor del trabajador cuando la empresa carece de registro fiable.

6. Real Decreto-ley 8/2019, de 8 de marzo, de medidas urgentes de protección social y de lucha contra la precariedad laboral en la jornada de trabajo (BOE núm. 61, 12 de marzo de 2019).

7. Estatuto de los Trabajadores, artículo 34.9. Obligación de registro diario de jornada.

8. Ley de Enjuiciamiento Civil, artículo 382. Instrumentos que permiten archivar, conocer o reproducir datos.

9. Ley sobre Infracciones y Sanciones en el Orden Social (LISOS), artículo 7.5. Infracción grave por incumplimiento del registro de jornada.

10. ISO 27037:2012. Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence.

11. RFC 3227. Guidelines for Evidence Collection and Archiving (IETF, febrero 2002).

12. UNE 71506:2013. Metodología para el análisis forense de las evidencias electrónicas.

13. ITSS — Memoria anual 2024. Inspección de Trabajo y Seguridad Social. Datos de actuaciones inspectoras en materia de tiempo de trabajo.

14. CC.OO. — Informe sobre horas extras en España 2024. Datos sobre horas extras no remuneradas y reclamaciones.

15. AEPD — Resoluciones sobre fichaje biométrico. Criterios sobre tratamiento de datos biométricos en el ámbito laboral.

16. Iberley — La pericial informática en el ámbito laboral. Análisis jurídico de la prueba pericial informática en procedimientos sociales. Disponible en: iberley.es.

17. Peritos-informaticos.com — Peritaje laboral de registros de fichaje. Metodología de análisis forense aplicada a sistemas de control horario. Disponible en: peritos-informaticos.com.

18. Tecnoperitaciones — Informe forense laboral. Guía sobre la elaboración de informes periciales informáticos en disputas laborales. Disponible en: tecnoperitaciones.com.

19. Peritoinformatico.es — Los metadatos como prueba pericial. Análisis del valor probatorio de los metadatos en el contexto forense. Disponible en: peritoinformatico.es.

20. Xataka — GPS, WhatsApp y email como prueba de despido. Reportaje sobre el uso de evidencia digital en despidos laborales. Disponible en: xataka.com.

21. El Independiente — WhatsApp como prueba en juicios laborales. Análisis periodístico sobre la admisibilidad de mensajes de WhatsApp en procedimientos laborales. Disponible en: elindependiente.com.

22. Elder Derecho — Carga de la prueba en reclamación de horas extras. Análisis jurídico de la inversión de la carga probatoria. Disponible en: elderecho.com.

23. Economist and Jurist — Horas extras y prueba digital. Artículo especializado sobre evidencia digital en reclamaciones de jornada. Disponible en: economistjurist.es.

24. Autónomos y Emprendedor — Responder al móvil fuera de horario es hora extra (enero 2026). Cobertura de la sentencia sobre atención telefónica fuera del horario laboral. Disponible en: autonomosyemprendedor.es.

25. Centro de Formación Pericial — Perito de registro horario. Formación sobre peritaje informático aplicado al control de jornada. Disponible en: centroformacionpericial.com.

26. Kronjop — Cumplimiento normativo del registro de jornada. Análisis de requisitos legales y técnicos. Disponible en: kronjop.com.

27. Daltico Equipo — Sistema de fichaje con integridad forense. Plataforma de registro de jornada con hash SHA-256, logs inmutables y cadena de custodia. Disponible en: daltico.com/es/productos/equipo/.

28. Código Penal, artículo 390. Falsedad en documento privado.

29. Reglamento General de Protección de Datos (RGPD), artículo 9. Tratamiento de categorías especiales de datos personales (incluidos datos biométricos).

30. NIST SP 800-86. Guide to Integrating Forensic Techniques into Incident Response. National Institute of Standards and Technology.

31. Ley 10/2021, de 9 de julio, de trabajo a distancia. Obligación de registro de jornada en teletrabajo.

32. Artículo 59.1 del Estatuto de los Trabajadores. Prescripción de acciones derivadas del contrato de trabajo (1 año para horas extras).

33. Artículo 217 de la Ley de Enjuiciamiento Civil. Carga de la prueba y reglas de distribución.

34. Artículo 348 de la Ley de Enjuiciamiento Civil. Valoración de la prueba pericial conforme a las reglas de la sana crítica.

35. Artículo 329 de la Ley de Enjuiciamiento Civil. Consecuencias de la negativa a exhibir documentos (ficta confessio).

36. ENAC — Entidad Nacional de Acreditación. Criterios de acreditación para laboratorios de informática forense en España. Disponible en: enac.es.

37. SHA-256 — FIPS PUB 180-4. Secure Hash Standard (SHS). National Institute of Standards and Technology, agosto 2015.

Conclusión

El registro de jornada ha pasado de ser un mero trámite administrativo a convertirse en una pieza clave de la litigiosidad laboral en España. La jurisprudencia del Tribunal Supremo (STS 1161/2024) y del TJUE (C-55/18) han elevado el listón: ya no basta con tener «algo» registrado. El sistema debe ser objetivo, fiable y accesible, y esa fiabilidad se mide en términos técnicos que un perito informático forense puede verificar.

Las técnicas forenses que he descrito en este artículo —verificación de hashes criptográficos, análisis de metadatos, inspección de logs de auditoría, detección de patrones estadísticos artificiales y correlación con fuentes externas— permiten determinar con alto grado de certeza si un registro de fichaje ha sido manipulado.

Las conclusiones clave que extraigo de mi experiencia son:

1. La integridad criptográfica es el estándar: Un sistema sin hash SHA-256 por registro es, desde la perspectiva forense, un sistema sin garantías. La diferencia entre detectar una manipulación en 2 horas (con hash) y en 2 semanas (sin hash, por métodos indirectos) es la diferencia entre un peritaje que convence y uno que no.

2. Los logs de auditoría inmutables son imprescindibles: Sin logs INSERT-only, no hay forma de rastrear quién hizo qué y cuándo. Y sin esa trazabilidad, el sistema no cumple el requisito de «objetivo» del TJUE.

3. La correlación con fuentes externas es enormemente poderosa: Incluso cuando el sistema de fichaje carece de integridad, la combinación de emails, VPN, WiFi, GPS y mensajería puede reconstruir la jornada real con precisión.

4. La carga de la prueba favorece al trabajador: Basta con aportar indicios razonables para que se invierta la carga. Un informe pericial que demuestre la vulnerabilidad del sistema de fichaje puede ser ese indicio.

5. La prevención es más barata que la condena: Invertir en un sistema de fichaje con garantías forenses (como Daltico Equipo) cuesta una fracción de lo que cuesta una condena por horas extras no registradas.

Si eres trabajador y sospechas que tu empresa manipula los registros de fichaje, el primer paso es preservar toda la evidencia de la que dispongas (mensajes, emails, capturas) y consultar con un abogado laboralista. El peritaje informático puede aportar la evidencia técnica que incline la balanza a tu favor.

Si eres empresa y quieres protegerte ante reclamaciones de jornada, el primer paso es evaluar la robustez técnica de tu sistema de fichaje actual utilizando la checklist de 10 puntos de la sección 13. Si el resultado es inferior a 6, tu sistema no te protegerá ante un tribunal.

Si eres abogado laboralista y necesitas un informe pericial sobre registros de fichaje, contacta conmigo para una primera valoración sin compromiso. Trabajo con metodología ISO 27037 y UNE 71506, y mis informes incluyen la documentación técnica necesaria para resistir una ratificación en vista oral.

Artículos relacionados que pueden interesarte:

• Análisis forense de WhatsApp: validez judicial en 2025 — Cómo un perito valida mensajes de WhatsApp como prueba, relevante cuando se usan como evidencia de horas extras fuera de horario.
• Cómo preparar evidencia digital para un proceso judicial — Guía general sobre la preparación de evidencia digital, aplicable a registros de fichaje.
• 5 errores comunes al recopilar pruebas digitales — Errores que invalidan la evidencia digital, incluyendo la cadena de custodia de registros laborales.
• Validar un informe pericial informático en juicio — Cómo se defiende un informe pericial durante la ratificación en vista oral.
• Contrainforme pericial informático: cuándo y cómo solicitarlo — Guía para impugnar un peritaje de la parte contraria.

¿Sospechas de manipulación en registros de fichaje? Como perito informático forense, analizo sistemas de registro de jornada para detectar alteraciones y generar informes con validez judicial. Primera valoración sin compromiso.

Solicitar análisis forense | Fichaje con integridad forense