A subject access request is an ordinary administrative event right up until it covers monitoring data, at which point most organisations discover they have never thought about what they would actually send.
The request itself is usually three sentences in an email. The deadline is one month. And the data is, in practice, harder to disclose than payroll or HR records, for reasons worth understanding before the email arrives rather than after.
The scope question, settled
Activity data is personal data. Application usage, focus time, working-hours patterns, idle detection, any score or category derived from them — all of it relates to an identifiable person and is therefore within scope of the right of access.
The two arguments people reach for do not work.
"We derived it, they did not give it to us" is irrelevant. Derived and inferred data about a person is still their personal data, and in some respects it is the more sensitive kind, because the person has no idea it exists until you tell them.
"It is aggregated" is only true if it genuinely is. If a manager can open a view that identifies one person, the underlying records are per-person and in scope. Aggregation as a presentation layer over individual records is not aggregation for this purpose. Our note on how long to keep monitoring data covers where the line sits, including the trap where small-team aggregates remain re-identifying.
Why this one is harder than an HR file
Three things make monitoring data awkward to disclose, and none of them is the volume.
It contains other people. A calendar-derived meeting record names attendees. A document title can identify a client, a deal or a colleague's performance review. Shared-session data covers whoever was in the session. The requester's right reaches their own data, not everyone else's, so the export has to be reviewed and redacted rather than dumped. That review is the work, and it is the reason a wholesale CSV export is the wrong instinct.
It needs explaining to be meaningful. Handing someone a column called productivity_score: 62 discharges nothing useful. The right of access includes being told the purposes of processing and, for automated decision-making, meaningful information about the logic. A number you cannot explain is a number you should not have been generating — which is a design question, not a disclosure one.
It is frequently requested adversarially. The realistic context for a monitoring DSAR is a grievance, a performance process, or someone who has just been told their role is at risk. They are asking because they expect the data to be used against them, or to have been used already. That does not change your obligation in the slightest, but it does mean the response will be read closely by someone with an incentive to find inconsistency, and possibly by their solicitor.
Getting ready before one arrives
The preparation is mostly inventory, and it takes an afternoon.
Write down every system that holds behavioural data about employees, including the ones nobody thinks of as monitoring — the ticketing system's timestamps, badge access, the VPN logs, the call platform. A DSAR covers all of it, and the systems people forget are the ones that produce an incomplete response.
For each, establish whether you can export one person's records without exporting everyone's. A surprising number of tools cannot, and discovering that inside a one-month deadline is unpleasant. This is worth asking vendors during evaluation — our vendor security review covers the field-level inventory question that makes this answerable.
Decide who owns the response, and make sure the request reaches them. DSARs frequently arrive addressed to a line manager who does not recognise what they are holding, and the month runs from arrival regardless.
Then write the explanation once, in advance. What each metric means, how it is derived, what it is used for and what it is not used for. You will need it every time, and writing it calmly beats writing it in week three of a deadline.
The design decision underneath all of this
The organisations that handle monitoring DSARs easily are the ones that collect less and show people their own data as a matter of course.
That is not a coincidence or a marketing line. If an employee can already see their own dashboard, a DSAR is largely a formality — you are confirming what they have been looking at, plus whatever sits behind it. If they cannot, the request is a discovery exercise into a system they have never seen, and every answer invites a follow-up.
The same applies to collection breadth. A metadata-only deployment produces a disclosure you can review in an hour. Screen captures produce one you cannot, because every frame may contain third-party data, client confidential material or the employee's own private browsing, and each has to be assessed. The screen monitoring piece prices that from the storage side; this is the same cost arriving through a different door.
Transparency is usually argued for on trust grounds. The administrative argument is less inspiring and quite persuasive on its own.
When the data cuts the other way
Worth noting, because it is the case nobody plans for: sometimes the data helps the employee and that is fine.
Someone claiming they were overloaded, or that after-hours work was expected of them, or that a workload was unmanageable, may well be right, and the monitoring data may well show it. A response that discloses evidence supporting their position is not a failure of the process. It is the process working, and attempting to avoid it is where organisations get into genuine trouble.
If your working-hours data would embarrass you in a DSAR, the problem is the working hours. The burnout signals piece covers reading them before someone has to ask.
Where ProdView fits
Two things make this easier with ProdView, both structural rather than features bolted on. The collection is narrow — activity and application metadata, never screen content or keystrokes — so the disclosure is reviewable and the third-party redaction problem is much smaller. And employees see the same dashboard their manager does, which turns a DSAR from a discovery exercise into a confirmation. There is no blended productivity score, so there is no number we would struggle to explain to the person it describes.
When not to pick us: you have a regulatory mandate for session recording. That is legitimate where it applies, and the DSAR burden that comes with it is part of the cost — budget review time, not just storage.
Try before you commit
Three seats are free forever. Export your own record and read it as though you had requested it; that is the fastest way to find out whether your current setup could answer in a month.
General information as of October 2026, not legal advice. Access rights and deadlines vary by jurisdiction; take advice on a live request.