¿Es lo mismo inmutabilidad que un sistema con permisos de edición restringidos?

No. Un sistema con permisos de edición restringidos solo controla quién puede modificar los datos, pero no impide técnicamente la modificación. La inmutabilidad real significa que el sistema hace técnicamente imposible (o criptográficamente detectable) cualquier alteración posterior al registro original. Un sistema con permisos puede ser manipulado por el administrador; un sistema verdaderamente inmutable no puede alterarse sin dejar evidencia verificable.

¿La blockchain es la única forma de garantizar la inmutabilidad de los registros de jornada?

No. Existen varias implementaciones técnicas de inmutabilidad: hash chains (cada registro incluye el hash del anterior, formando una cadena verificable), WORM storage (almacenamiento de escritura única), Merkle trees, sellos de tiempo cualificados (eIDAS), y almacenamiento en nube con inmutabilidad certificada. Blockchain es la solución más conocida pero también la más compleja y costosa. Para la mayoría de empresas, un sistema de hash chains con sello de tiempo cualificado ofrece las mismas garantías de forma más eficiente.

¿Cómo puedo verificar que mi sistema de registro horario es realmente inmutable?

Mediante análisis forense: un perito informático puede auditar el sistema para comprobar si existen mecanismos técnicos de inmutabilidad (hash chain, blockchain, WORM), si el log de auditoría es él mismo inmutable, y si los sellos de tiempo son verificables frente a una autoridad de sellado reconocida. La verificación más simple es intentar modificar un registro antiguo y comprobar si el sistema detecta la discrepancia mediante hash.

Inmutabilidad de Registros: Integridad y Valor Probatorio

Un registro digital sin inmutabilidad no es evidencia: es un documento editable. Esta es la premisa fundamental que los tribunales españoles han comenzado a interiorizar al valorar los registros de jornada como prueba en litigios laborales. La distinción entre un fichero Excel con datos de jornada —que cualquier administrador puede modificar sin dejar rastro si el sistema no tiene log de auditoría— y un sistema de registro con inmutabilidad garantizada mediante hash o blockchain es la diferencia entre una prueba impugnable y una prueba sólida. Con el proyecto de nueva ley de jornada de 2025-2026 apuntando a requisitos técnicos más estrictos para los sistemas de registro, la inmutabilidad deja de ser una característica diferenciadora para convertirse en un requisito de cumplimiento.

Concepto técnico de inmutabilidad

En el contexto de sistemas de información, inmutabilidad es la propiedad que garantiza que los datos, una vez escritos en el sistema, no pueden ser modificados ni eliminados sin que esa modificación sea técnicamente detectable.

La inmutabilidad se expresa en dos variantes:

Variante	Descripción	Aplicación
Inmutabilidad fuerte (WORM)	Write-Once, Read-Many: el soporte físico o lógico no permite sobreescritura bajo ninguna circunstancia	Almacenamiento de registros en sistemas WORM certificados
Inmutabilidad verificable (hash chain)	Los datos pueden existir en soportes modificables, pero cualquier alteración es criptográficamente detectable	Sistemas de fichaje con hash chain, blockchain privada

Inmutabilidad vs. integridad

La inmutabilidad es la propiedad del sistema; la integridad es la propiedad del dato. Un sistema inmutable garantiza la integridad del dato. Un sistema sin inmutabilidad puede tener datos con integridad aparente, pero esa integridad no es demostrable sin evidencia adicional (logs de auditoría, testigos, etc.).

Implementaciones técnicas de inmutabilidad

1. WORM Storage (Write-Once, Read-Many)

Los sistemas WORM son soportes de almacenamiento que solo permiten la escritura una vez. Una vez escrito el dato, el soporte —o la partición lógica configurada como WORM— no acepta operaciones de modificación o borrado.

Implementaciones comerciales:

Producto	Tipo	Certificación
Amazon S3 Object Lock	Cloud (modo WORM lógico)	FINRA, SEC Rule 17a-4
Azure Blob Immutable Storage	Cloud (modo WORM lógico)	SEC 17a-4, CFTC
NetApp ONTAP SnapLock	Software WORM sobre hardware estándar	SEC 17a-4
Optical WORM (CD-R, DVD-R)	Físico	No borrable físicamente

Aplicación en registro horario: Un sistema de fichaje que escribe cada registro de jornada en un bucket S3 con Object Lock activado en modo “Compliance” garantiza que ni el administrador puede eliminar el registro antes de que expire el período de retención configurado (mínimo 4 años para cumplir el art. 34.9 ET).

2. Hash Chains

Una hash chain es una estructura en la que cada registro incluye, como parte de su contenido, el hash criptográfico del registro anterior. Esto crea una cadena donde modificar cualquier elemento invalida el hash de todos los elementos posteriores.

Estructura de una hash chain en un registro de jornada:

Registro #001:
  timestamp: 2026-02-23T08:02:15Z
  empleado: EMP_0047
  evento: ENTRADA
  hash_anterior: 0000000000000000 (primer registro)
  hash_propio: SHA256(timestamp+empleado+evento+hash_anterior)
  = a3f2b8c9d4e5f6a1...

Registro #002:
  timestamp: 2026-02-23T08:02:47Z
  empleado: EMP_0051
  evento: ENTRADA
  hash_anterior: a3f2b8c9d4e5f6a1... (hash del Registro #001)
  hash_propio: SHA256(timestamp+empleado+evento+hash_anterior)
  = 7c8d9e0f1a2b3c4d...

Si alguien modifica el Registro #001:
  - Su hash cambia a, por ejemplo, 99a1b2c3...
  - El hash_anterior del Registro #002 ya no coincide con el hash calculado del #001
  - La cadena está rota: manipulación detectable

Ventajas de las hash chains:

Sin coste de infraestructura blockchain
Verificación instantánea de cualquier segmento de la cadena
Combinable con sellos de tiempo cualificados para añadir referencia temporal certificada

3. Blockchain y DLT (Distributed Ledger Technology)

La blockchain forense aplicada al registro de jornada utiliza una red de cadena de bloques (pública, privada o consorcio) donde cada registro de fichaje se escribe como una transacción.

Características en el contexto laboral:

Propiedad	Descripción
Descentralización	Los datos no dependen de un único servidor controlado por la empresa
Consenso	La adición de un registro requiere validación por múltiples nodos
Inmutabilidad	La modificación de un bloque requeriría el recálculo de toda la cadena en todos los nodos
Timestamp embebido	Cada bloque tiene timestamp que forma parte de su propio hash

Limitaciones:

Coste de infraestructura y latencia (especialmente en redes públicas)
El RGPD y el “derecho al olvido” son difícilmente compatibles con blockchains públicas
Para registro de jornada, una blockchain privada o de consorcio es más adecuada

4. Merkle Trees

Un árbol de Merkle es una estructura de datos en árbol donde cada hoja contiene el hash de un dato, y cada nodo intermedio contiene el hash combinado de sus hijos. Esta estructura permite verificar la integridad de un único registro sin necesidad de revelar ni procesar todos los demás registros.

Si se quiere verificar que un registro concreto no ha sido alterado, solo se necesita una prueba de Merkle (los hashes de los nodos hermanos en el camino hasta la raíz), sin revelar el contenido de los demás registros. Esto es especialmente útil para auditorías parciales que verifican un período concreto sin exponer todos los datos de jornada de la empresa.

5. Sellos de tiempo cualificados (eIDAS)

El sello de tiempo cualificado es un servicio prestado por entidades de confianza reconocidas bajo el Reglamento eIDAS (Reglamento UE 910/2014) que vincula criptográficamente un documento o conjunto de datos a un momento temporal determinado.

El sello de tiempo cualificado tiene valor probatorio reforzado

Según el art. 41.2 del Reglamento eIDAS, “un sello de tiempo electrónico cualificado gozará de la presunción de exactitud de la fecha y la hora que indica y de la integridad de los datos a los que dicha fecha y hora están vinculados”. Combinado con un hash SHA-256 del registro, proporciona una prueba de que ese registro existía con ese contenido en ese momento determinado.

Proveedores de sello de tiempo cualificado en España:

FNMT-RCM (Fábrica Nacional de Moneda y Timbre)
Camerfirma
Izenpe
AC Camerfirma (acreditada bajo eIDAS)

Aplicación en el registro horario laboral

Qué exige el marco legal actual

El artículo 34.9 del Estatuto de los Trabajadores (en su redacción vigente tras el RDL 8/2019) no menciona explícitamente la “inmutabilidad”, pero establece que los registros deben ser:

Fidedignos: que reflejen la jornada real
Conservados durante 4 años: accesibles para la ITSS y los representantes de los trabajadores
Disponibles inmediatamente: en cualquier momento de inspección

El Criterio Técnico ITSS 101/2019 aclara que el sistema debe garantizar que los datos no han sido alterados retroactivamente. Un sistema sin inmutabilidad no puede demostrar esta garantía.

Qué apunta la nueva regulación en tramitación (2025-2026)

El proyecto de reforma del Estatuto de los Trabajadores en tramitación contempla requisitos técnicos adicionales para los sistemas de registro, incluyendo la referencia a la “integridad técnica verificable” y la posibilidad de acceso remoto por parte de la ITSS. Aunque la redacción definitiva puede variar, la dirección regulatoria apunta claramente hacia sistemas con inmutabilidad verificable, alejándose de las hojas de Excel y los sistemas sin log de auditoría.

Diferencia práctica: sistema sin inmutabilidad vs. con inmutabilidad

Escenario	Sistema sin inmutabilidad	Sistema con inmutabilidad
Reclamación de horas extra	El empleador puede editar los registros antes del juicio y alegar que así estaban	El perito puede verificar que los registros no han sido alterados desde el registro original
Inspección de Trabajo	La empresa puede haber limpiado datos antes de la visita; la ITSS no puede probarlo sin el log	La cadena de hash o blockchain demuestra qué datos existían y cuándo
Despido disciplinario	El trabajador puede cuestionar la autenticidad del registro presentado como prueba	El registro con hash chain y sello de tiempo es técnicamente auténtico y verificable
Coartada falsa	Posible alterar el registro para que aparezca un fichaje que no existió	Imposible introducir un registro con timestamp pasado sin romper la cadena

Cómo verificar la inmutabilidad de un sistema de registro

La verificación forense de si un sistema de registro es verdaderamente inmutable sigue este proceso:

Revisión de la arquitectura del sistema: El perito solicita la documentación técnica del sistema (especificaciones, diagrama de base de datos, manual de administrador). Se buscan referencias explícitas a mecanismos de inmutabilidad: hash chain, WORM, blockchain, sello de tiempo.
Análisis del esquema de base de datos: Si el sistema usa una base de datos relacional, se examina si existen campos de hash en las tablas de registro y si hay triggers o stored procedures que calculen y almacenen el hash al insertar cada fila.
Prueba de integridad (challenge test): El perito calcula el hash SHA-256 de un registro antiguo conocido y lo compara con el hash almacenado en el sistema. Si coincide, el registro no ha sido alterado. Si no coincide, el sistema ha sido manipulado o el mecanismo de hash no funciona correctamente.
Verificación del sello de tiempo: Si el sistema usa sellos de tiempo cualificados, el perito verifica la firma del sello contra el certificado de la autoridad de sellado (TSA). Un sello válido y no expirado confirma la existencia del dato en el momento indicado.
Intento de modificación controlada: En un entorno de prueba (nunca en producción), el perito intenta modificar un registro y comprueba si el sistema detecta la discrepancia en el hash chain. Esta es la prueba definitiva de que el mecanismo de inmutabilidad funciona correctamente.
Revisión de permisos de base de datos: Un sistema con hash chain pero donde el administrador de base de datos puede modificar directamente la tabla (bypass de la aplicación) y recalcular el hash no ofrece inmutabilidad real. El perito verifica que los permisos de base de datos impiden la modificación directa fuera de la aplicación.

Estándares internacionales

ISO 27001:2022 - Annex A

El Annex A del estándar ISO 27001:2022 incluye el control A.5.33 “Protección de registros”, que requiere que los registros estén protegidos contra pérdida, destrucción, falsificación, acceso no autorizado y divulgación no autorizada. La inmutabilidad es la implementación técnica natural de este control cuando los registros tienen valor probatorio.

NIST SP 800-92 (Log Management)

El NIST Special Publication 800-92 “Guide to Computer Security Log Management” establece como buena práctica que los logs con valor probatorio deben protegerse con mecanismos de integridad (hashing, firma digital) y que deben existir controles que impidan su modificación retroactiva.

Reglamento eIDAS (UE 910/2014)

Regula los servicios de confianza en la UE, incluyendo los sellos de tiempo cualificados. El art. 41 establece su valor probatorio reforzado.

ENS (Esquema Nacional de Seguridad, RD 311/2022)

El ENS en su categoría Media y Alta requiere controles de integridad de los logs del sistema, lo que en la práctica implica mecanismos similares a la inmutabilidad para los registros de mayor sensibilidad.

Marco legal en España aplicable a la inmutabilidad de registros laborales

1. Estatuto de los Trabajadores (RDL 2/2015), art. 34.9:

Obligación de conservar registros de jornada durante 4 años con fidedignidad demostrable.

2. Real Decreto-ley 8/2019, de 8 de marzo:

Obliga al registro diario de jornada y a su disponibilidad para la ITSS. Un sistema sin integridad verificable no puede demostrar que los datos disponibles son los originales.

3. Criterio Técnico ITSS 101/2019:

El sistema de registro debe garantizar la no alteración retroactiva de los datos. Esto es, en la práctica, un requisito de inmutabilidad verificable.

4. Reglamento eIDAS (UE 910/2014), art. 41:

Valor probatorio de los sellos de tiempo cualificados: presunción de exactitud del timestamp y de integridad del dato sellado.

5. LEC (Ley 1/2000), arts. 299 y 326:

Regulación de la prueba documental electrónica. Los documentos electrónicos cuya autenticidad e integridad no pueden verificarse tienen menor valor probatorio.

6. ISO 27001:2022, Annex A.5.33:

Estándar de referencia técnica para la protección de registros con valor probatorio.

Caso práctico: sistema sin inmutabilidad vs. sistema con hash chain en juicio

Nota: Caso construido sobre patrones de litigios laborales relacionados con registros digitales entre 2022 y 2025.

Caso A: empresa con sistema sin inmutabilidad

Una empresa de servicios profesionales presenta en juicio por despido el registro de jornada de los últimos 6 meses del trabajador, extraído de su sistema de RRHH. El trabajador alega que el registro ha sido manipulado para eliminar horas extra.

El perito designado por el trabajador analiza el sistema:

Sistema: Aplicación web de RRHH, base de datos PostgreSQL
Esquema de la tabla de registros:
  - id (integer, primary key)
  - empleado_id (integer)
  - fecha (date)
  - hora_entrada (time)
  - hora_salida (time)
  - modificado_por (varchar)
  - fecha_modificacion (timestamp)

Hallazgo:
  - El campo hora_salida es modificable directamente
  - No existe campo de hash ni mecanismo de verificación de integridad
  - El log de auditoría muestra 23 modificaciones en el período litigioso
  - Dirección de las modificaciones: todas reducen la hora de salida
  - No es posible determinar cuál era el valor original antes de la modificación
    (el sistema solo guarda el valor actual, no el histórico)

Resultado: El perito concluye que el sistema no ofrece garantías de inmutabilidad y que las 23 modificaciones son verificables pero los valores originales no son recuperables. El juzgado valora la prueba de forma desfavorable para la empresa y aplica la inversión de la carga probatoria del art. 34.9 ET.

Caso B: empresa con sistema con hash chain

La misma situación, pero la empresa utilizaba un sistema con hash chain y sello de tiempo cualificado emitido por FNMT-RCM para cada registro.

Verificación pericial:
  - Hash SHA-256 del registro de entrada del trabajador el 15/09/2025 08:03:22:
    Almacenado en sistema: a3f2b8c9...
    Calculado sobre los datos actuales: a3f2b8c9... (COINCIDE)
  - Sello de tiempo cualificado FNMT de ese registro:
    Timestamp: 2025-09-15T08:03:22Z (verificado contra certificado TSA vigente)
    Integridad del sello: VÁLIDA
  - Hash chain: los 847 registros del período forman una cadena continua sin rupturas

Resultado: El perito certifica que los registros del período litigioso son íntegros y no han sido alterados desde su creación. La empresa acredita la jornada real del trabajador y el juzgado desestima la reclamación de horas extra.

Comparativa de implementaciones

Implementación	Coste infraestructura	Complejidad	Valor probatorio	RGPD-friendly
WORM (S3 Object Lock)	Bajo-Medio	Baja	Muy alto	Sí
Hash chain simple	Muy bajo	Media	Alto	Sí
Hash chain + sello de tiempo	Bajo	Media	Muy alto	Sí
Blockchain privada	Alto	Alta	Muy alto	Sí (con control)
Blockchain pública	Medio	Alta	Muy alto	Problemático (derecho al olvido)
Merkle tree	Muy bajo	Alta	Alto	Sí
Sin inmutabilidad	Ninguno	Ninguna	Bajo (impugnable)	N/A

Conceptos relacionados

Hash criptográfico - Mecanismo técnico fundamental que habilita la inmutabilidad verificable
SHA-256 - Algoritmo de hash recomendado para implementaciones de inmutabilidad
Blockchain forense - Tecnología DLT que proporciona inmutabilidad distribuida
Registro horario digital - Sistema cuya inmutabilidad es crítica para su valor probatorio
Auditoría de registro horario - Proceso que verifica la inmutabilidad del sistema

Referencias y fuentes

Real Decreto Legislativo 2/2015, art. 34.9 (registro de jornada). boe.es
Real Decreto-ley 8/2019, de 8 de marzo. boe.es
Reglamento (UE) 910/2014 (eIDAS), art. 41: valor probatorio de los sellos de tiempo cualificados. eur-lex.europa.eu
ISO/IEC 27001:2022, Annex A, control A.5.33 (protección de registros). ISO.
NIST SP 800-92. (2006). Guide to Computer Security Log Management. nist.gov
Real Decreto 311/2022, por el que se regula el Esquema Nacional de Seguridad. boe.es
FNMT-RCM. Servicio de sellado de tiempo cualificado. fnmt.es
Amazon Web Services. S3 Object Lock documentation: compliance and governance modes. docs.aws.amazon.com
ITSS. Criterio Técnico 101/2019 sobre actuaciones en materia de registro de jornada. mites.gob.es
STS (Sala 4ª) de 2 de marzo de 2021, rec. 3595/2018: Sobre el valor probatorio del registro de jornada y la carga de la prueba en reclamaciones de horas extraordinarias.

¿Necesitas verificar si tu sistema de registro horario ofrece inmutabilidad real y valor probatorio en caso de litigio? Contacta con Digital Perito para una auditoría forense de integridad de tu sistema de fichaje.

Última actualización: febrero 2026 Categoría: Técnico Código: EXT-017

Inmutabilidad de Registros