The Worker's Own Record
Accessibility is part of the recording standard and the cheapest quality control available. What routine access should show.
Procedure
Where a duty to record working time exists, the system must be accessible to the worker. This is the requirement most often missed and the one that costs least to meet.
Why it is part of the standard
A record the worker cannot see cannot protect them. The whole purpose of the duty is to make working time limits and rest periods enforceable, and enforcement requires evidence the person can reach.
It also makes the record credible. A figure the worker has seen and not disputed is worth considerably more in a dispute than one produced afterwards.
And it is the cheapest data quality control there is: people correct their own records when they can see them, and nobody else has the knowledge to.
What routine access should show
Their own daily record: start, end, breaks, total, for any period.
Their cumulative hours against contracted, over the week, month and reference period.
Rest periods, computed from actuals, with any shortfall visible.
Every edit made to their record, by whom and when.
Their own project attribution, which is what they entered.
Not: anyone else's data, and not a comparison against colleagues.
What it should not require
A request. Routine self-service, not a subject access process.
A manager's involvement.
A separate login to a system they otherwise do not use.
An export in a format nobody can read.
Corrections
A route to dispute an entry, with a named person and a response time.
The dispute logged with its outcome.
Corrections visible rather than silent, with the original retained.
A cluster of disputes around one team, one rule or one shift pattern is a configuration finding, not a set of individual complaints, and reviewing the log is how you notice.
Subject access requests
They arrive, usually during a dispute or after a departure.
Know in advance what would be produced: the time record, any edits, any derived reports, any monitoring data if it exists.
Know the statutory response period and whether you can meet it.
Test it once, on a volunteer, which is also the fastest way to discover that retention is longer than anyone thought.
Routine access reduces these substantially, because most requests are asking for something the person should simply have been able to see.
Testing a subject access request
Run it once, on a volunteer, before it arrives during a dispute.
Produce everything held about that person: time record, edits, derived reports, any monitoring data.
Time how long it takes.
Check the statutory response period and whether you would meet it.
Note what you found that you did not expect to be holding, which is the usual outcome and the reason to do it.
Routine self-access reduces these substantially, because most requests ask for something the person should simply have been able to see.
On departure
The point at which records are most often mishandled.
Provide an export as part of the exit process, rather than on request.
Retain what the law requires and delete the rest, on schedule, verified.
Monitoring data, where any exists, goes first, since it rarely has a retention justification beyond the current period.
Remove access promptly, including any manager view of the departed person's data.
People frequently want their records and are entitled to them in many jurisdictions, and providing them unprompted costs nothing.
Turn the principle into a test
For an example that can make this requirement testable, consult the healthcare workflow. Treat the page as a starting point rather than proof: reproduce the workflow with real roles, exceptions and permissions before relying on the result.