¿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 muchas empresas, una hash chain con anclaje periódico mediante sello de tiempo cualificado ofrece una garantía suficiente de integridad y existencia temporal con menor complejidad, aunque no reproduce la distribución ni el modelo de consenso de una blockchain.

¿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 prueba más concluyente es intentar modificar un registro antiguo y comprobar si el sistema detecta la discrepancia, pero se hace siempre sobre un entorno de prueba, nunca sobre el sistema en producción: alterar registros reales de jornada destruye la evidencia que se pretendía auditar. Y hay un límite que conviene conocer de antemano: si quien administra el sistema puede reescribir los datos y recalcular la cadena entera, la coherencia interna vuelve a cuadrar. Lo que cierra esa vía es un anclaje externo, como un sello de tiempo cualificado periódico sobre el estado de la cadena.

Inmutabilidad de Registros: Integridad y Valor Probatorio

Un registro digital sin mecanismos de inmutabilidad puede aportarse como prueba, pero su autenticidad e integridad pueden requerir acreditación adicional y su fuerza probatoria se valora en el caso concreto. La diferencia relevante no es entre «evidencia» y «no evidencia», sino entre un registro cuya historia puede verificarse técnicamente y otro cuya eventual modificación hay que reconstruir mediante logs, copias, testigos u otros elementos. Un fichero Excel de jornada que cualquier administrador puede modificar sin dejar rastro y un sistema con inmutabilidad verificable mediante hash o blockchain no se distinguen por ser o no ser prueba, sino por lo fácil que resulta sostener su integridad cuando la otra parte la discute. Y eso importa hoy, sin esperar a ninguna reforma: el art. 34.9 ET no exige inmutabilidad, pero quien no puede acreditar que su registro no ha sido alterado parte en desventaja probatoria si la contraparte acredita una posibilidad real de manipulación.

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	Solución WORM integrada de hardware y software	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
Resistencia a la alteración	Modificar un bloque obliga a rehacer los bloques posteriores y a conseguir que la cadena alterada sea aceptada conforme a las reglas de consenso; la dificultad depende del diseño y del control efectivo de la red
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 cualificado tiene valor probatorio reforzado — y el no cualificado también sirve

El art. 41 del Reglamento eIDAS dice dos cosas, y la primera se omite casi siempre:

«1. No se denegarán efectos jurídicos ni admisibilidad como prueba en procedimientos judiciales a un sello de tiempo electrónico por el mero hecho de estar en formato electrónico o de no cumplir los requisitos de sello cualificado. 2. Los sellos cualificados de tiempo electrónicos disfrutarán de una presunción de exactitud de la fecha y hora que indican y de la integridad de los datos a los que la fecha y hora estén vinculadas.»

Es decir: un sello no cualificado es admisible igualmente; lo que aporta el cualificado es la presunción, que traslada el esfuerzo a quien lo discuta. Combinado con el hash SHA-256 del registro, acredita que ese registro existía con ese contenido en ese momento.

Cómo se comprueba que un prestador es cualificado. No por su reputación ni por lo que anuncie: los prestadores entran y salen de la condición de cualificados, de modo que un listado publicado envejece mal. El criterio operativo lo da el propio art. 326.4 LEC, que ata la presunción a que el servicio «figuraba, en el momento relevante a los efectos de la discrepancia, en la lista de confianza de prestadores y servicios cualificados».

Dos consecuencias para un peritaje: la comprobación se hace sobre la lista de confianza oficial, y se hace referida a la fecha del sello, no a la de hoy. Que un prestador siga o no siendo cualificado ahora es irrelevante si lo era cuando selló.

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 la «inmutabilidad». Exige un registro diario con la hora concreta de inicio y finalización de la jornada, su organización y documentación por negociación colectiva o acuerdo de empresa, la conservación durante cuatro años y que permanezca a disposición de las personas trabajadoras, sus representantes legales y la Inspección de Trabajo y Seguridad Social (ITSS).

El Criterio Técnico 101/2019 de la ITSS interpreta que puede emplearse cualquier medio que garantice la fiabilidad y veracidad del registro, que los datos deben ser accesibles de manera inmediata desde el centro de trabajo y que el sistema ha de garantizar su no alteración a posteriori. La inmutabilidad verificable es una posible implementación técnica de esas garantías, no la única que el criterio admite ni un término empleado por el art. 34.9 ET.

Sobre las reformas anunciadas

Circulan desde 2025 propuestas para endurecer los requisitos técnicos del registro de jornada —integridad verificable, acceso remoto de la ITSS—, con distinta suerte parlamentaria. Mientras no haya texto publicado en el BOE, no son marco aplicable, y un informe pericial que se apoye en un anteproyecto queda desfasado en cuanto cambie la tramitación.

Lo que sí puede afirmarse hoy, sin depender de ninguna reforma, es que la impugnación no invalida por sí sola el registro. El art. 217.7 LEC obliga al tribunal a tener presente la disponibilidad y facilidad probatoria de cada parte: quien administra el sistema de fichaje controla la prueba y responde de su fiabilidad. En la STS 1161/2024, de 24 de septiembre, las sospechas sobre el registro no prosperaron porque no se demostró falta de fiabilidad, objetividad o trazabilidad ni una deficiencia técnica que permitiera alterar los datos. La ausencia de controles de integridad puede debilitar el registro cuando se acredita una posibilidad real de alteración, pero el resultado depende de la prueba del caso.

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	Con anclaje externo (sello de tiempo), la cadena permite verificar qué datos existían y cuándo; sin él, solo detecta incoherencias respecto de la cadena disponible
Despido disciplinario	El trabajador puede cuestionar la autenticidad del registro presentado como prueba	El registro con hash chain y sello de tiempo cualificado permite verificar su integridad posterior y su existencia en el momento sellado; no acredita por sí solo la autoría ni la veracidad del fichaje
Fichaje introducido a posteriori	Posible alterar el registro para que aparezca un fichaje que no existió	Insertar un registro con fecha pasada rompe la cadena — salvo que se rehaga entera, que es lo que un anclaje externo impide

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 y lo compara con una referencia original protegida o anclada fuera del alcance de quien podía modificar el registro. La coincidencia con esa referencia independiente acredita que el registro no ha sido alterado; si el dato y su hash están bajo el mismo control, la mera coincidencia solo prueba conformidad interna, no integridad histórica.
Verificación del sello de tiempo: Si el sistema usa sellos de tiempo cualificados, el perito valida criptográficamente el sello y comprueba la cadena de certificación, el estado histórico del servicio cualificado y la información de revocación referida al momento del sellado. La expiración actual del certificado no invalida por sí sola un sello histórico cuando existen las pruebas de validación a largo plazo necesarias.
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. El ensayo confirma el comportamiento del mecanismo en el entorno y la ruta probados; debe completarse con la revisión de permisos, rutas privilegiadas, configuración y su correspondencia con el sistema en producción.
Revisión de permisos de base de datos: un sistema con hash chain pero donde el administrador puede modificar directamente la tabla (saltándose la aplicación) y recalcular toda la cadena no ofrece inmutabilidad real. El perito verifica que los permisos impiden la modificación directa fuera de la aplicación.

Una hash chain sin anclaje externo la puede rehacer quien controla el sistema

Es el límite que decide si el mecanismo sirve, y conviene tenerlo claro antes de escribir «inalterable» en un informe. Una cadena de hashes solo demuestra coherencia interna: si quien administra el sistema puede reescribir los registros y recalcular la cadena entera, el resultado vuelve a ser coherente y no queda rastro. El paso 6 de arriba comprueba exactamente eso.

Lo que cierra esa vía es un anclaje externo fuera del control de la empresa: un sello de tiempo cualificado sobre el estado de la cadena a intervalos regulares, publicar periódicamente la raíz de Merkle, o cualquier tercero que conserve una constancia independiente. Sin ese anclaje, la hash chain protege frente a modificaciones descuidadas, no frente a quien controla la máquina — y esa es la diferencia entre un obstáculo y una garantía.

Estándares internacionales

ISO 27001:2022 - Annex A

El Anexo A de ISO/IEC 27001:2022 incluye el control A.5.33 «Protección de registros», un control de referencia sobre la protección de los registros frente a pérdida, destrucción, falsificación, acceso y divulgación no autorizados. Su aplicabilidad y la implementación concreta se determinan mediante el tratamiento del riesgo y la Declaración de Aplicabilidad; la inmutabilidad puede ser una de las medidas, no una exigencia universal del estándar.

NIST SP 800-92 (Log Management)

El NIST Special Publication 800-92 «Guide to Computer Security Log Management» recomienda calcular y conservar de forma segura un resumen (hash) de los logs archivados para detectar cambios, y señala que evitar la alteración de los originales favorece su uso probatorio. No formula una regla universal ni afirma que el hash impida modificar el log.

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 (RD 311/2022), en su medida op.exp.8 (registro de la actividad), se gradúa por el nivel de la dimensión de trazabilidad: para los niveles MEDIO y ALTO añade revisión, sincronización temporal, retención y control de acceso, y los registros solo pueden ser accedidos o eliminados por personal autorizado. El precepto no prescribe por sí mismo WORM ni una hash chain.

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

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

Registro diario con la hora concreta de inicio y fin de la jornada; conservación durante cuatro años a disposición de las personas trabajadoras, sus representantes legales y la ITSS. No emplea el término «inmutabilidad».

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

Introdujo la obligación de registro diario de jornada y su puesta a disposición de las personas trabajadoras, sus representantes y la ITSS. Un sistema sin integridad verificable no puede demostrar que los datos disponibles son los originales.

3. Criterio Técnico ITSS 101/2019:

Interpreta que el sistema debe garantizar la fiabilidad, veracidad y no alteración a posteriori de los datos, por cualquier medio que lo consiga. La inmutabilidad verificable es una implementación posible, no la única admitida.

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. 217.7, 299, 326.3 y 326.4:

El 217.7 reparte la carga según la disponibilidad y facilidad probatoria de cada parte. El 299 enumera los medios de prueba. El 326.3 remite al procedimiento del 326.2 cuando el servicio de confianza no era cualificado; el 326.4 presume la característica cuestionada cuando sí lo era y traslada a quien impugna la carga de comprobarlo.

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

Escenario ilustrativo

Los dos casos de esta sección son escenarios construidos sobre tipologías reales de la práctica pericial: contrastan qué puede acreditarse con un sistema y con otro, no relatan procedimientos concretos. Los perfiles, cifras y desenlaces no corresponden a un litigio identificable.

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)

Lo que puede concluir el perito: el sistema no ofrece garantías de inmutabilidad, y las 23 modificaciones son verificables pero los valores originales no son recuperables. Nótese lo que eso significa y lo que no: el peritaje acredita que hubo modificaciones y en qué dirección, no acredita cuál era el dato verdadero.

La carga de la prueba no se invierte por el art. 34.9 ET — ahí no dice nada de eso

Es la atribución errónea más repetida en este terreno. El art. 34.9 ET obliga al registro diario, a organizarlo por negociación colectiva o acuerdo, y a conservarlo cuatro años a disposición de trabajadores, representantes e ITSS. Ni una palabra sobre carga probatoria.

Los preceptos que sí operan son dos, y no dicen lo mismo:

Art. 217.7 LEC — no invierte la carga: obliga al tribunal a «tener presente la disponibilidad y facilidad probatoria que corresponde a cada una de las partes». Quien administra el sistema de fichaje controla la prueba, y responde de que sea fiable. Es modulación, no inversión.
Art. 326.4 LEC — aquí sí hay un desplazamiento, y es el que interesa a este glosario: si se usó un servicio de confianza cualificado, «se presumirá que el documento reúne la característica cuestionada», y «si aun así se impugnare (…) la carga de realizar la comprobación corresponderá a quien haya presentado la impugnación».

La diferencia es práctica: sin sello cualificado, el sistema fiable ayuda al que lo tiene; con sello cualificado, quien impugna carga con la comprobación. Escribir «inversión del art. 34.9» en un informe es dar un artículo que la contraparte abrirá para comprobar que no dice eso.

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 (sello FNMT-RCM validado: cadena y estado histórico del servicio en esa fecha)
    Integridad del sello: VÁLIDA
  - Hash chain: los 847 registros del período forman una cadena continua sin rupturas

Lo que puede concluir el perito: que los registros del período no han sido alterados desde que se sellaron, y que existían con ese contenido en la fecha que indica el sello. Es una afirmación fuerte y acotada — no dice que el trabajador fichara cuando debía, ni que el fichaje refleje la jornada real: dice que nadie tocó el dato después.

Esa distinción es la que sostiene el dictamen. Un registro íntegro de un fichaje falso sigue siendo un registro íntegro; lo que la inmutabilidad cierra es la vía de discutir la manipulación posterior, no la de discutir el contenido original.

Comparativa de implementaciones

Implementación	Coste infraestructura	Complejidad	Propiedad técnica aportada	RGPD-friendly
WORM (S3 Object Lock)	Bajo-Medio	Baja	Impide sobreescritura y borrado durante la retención	Sí
Hash chain simple	Muy bajo	Media	Detecta alteraciones salvo que se rehaga la cadena entera	Sí
Hash chain + sello de tiempo	Bajo	Media	Integridad posterior + existencia en el tiempo sellado	Sí
Blockchain privada	Alto	Alta	Integridad con distribución y consenso controlados	Sí (con control)
Blockchain pública	Medio	Alta	Integridad con distribución y consenso abiertos	Problemático (derecho al olvido)
Merkle tree	Muy bajo	Alta	Verificación parcial sin exponer todo el conjunto	Sí
Sin inmutabilidad	Ninguno	Ninguna	Ninguna; la integridad exige prueba adicional	N/A

Ninguna de estas tecnologías tiene asignado por ley un «valor probatorio» general: su eficacia se valora en el caso concreto. Solo el sello de tiempo cualificado goza de la presunción del art. 41.2 eIDAS sobre la fecha, la hora y la integridad de los datos sellados.

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, Anexo A, control A.5.33 (protección de registros). iso.org
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. Sellado de tiempo cualificado (CERES). Estado histórico del servicio en la lista de confianza de España visualizada por la Comisión Europea.
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. PDF del Criterio Técnico 101/2019
STS 1161/2024, de 24 de septiembre (Sala de lo Social, rec. 236/2022 — ROJ STS 4744/2024 · ECLI:ES:TS:2024:4744), conflicto colectivo sobre el registro de jornada del BBVA. En el caso enjuiciado, las sospechas sobre el sistema no prosperaron porque no se demostró falta de fiabilidad, objetividad o trazabilidad ni una deficiencia técnica que permitiera alterar los datos. Junto al art. 217.7 LEC, sobre disponibilidad y facilidad probatoria.

La comprobación no se hace leyendo el folleto del fabricante: se hace sobre el esquema de la base de datos, los permisos y un intento controlado de modificación. La firma un perito informático forense, que responde de esas conclusiones ante el tribunal.

Un sistema de fichaje se dice inmutable; que lo sea se comprueba

Una hash chain que el administrador puede recalcular entera protege frente a descuidos, no frente a quien controla la máquina. Auditoría de integridad del sistema de registro: esquema, permisos, sellos de tiempo y prueba de modificación controlada.

Ver el servicio de informes periciales

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

Inmutabilidad de Registros