gdpr and screen recording

gdpr and screen recording is really two questions, not one: recording your own screen and recording somebody else's sit in completely different places in the law, and almost every article on the subject collapses them together.

gdpr does not regulate tools. it regulates processing of personal data, and it cares about who is doing it, to whom, and why. so the same screen recorder can be entirely out of scope in one setup and a high risk processing activity in another.

this is the map, current as of september 2026. it is not legal advice, and a 10 minute conversation with a real data protection lawyer is worth more than any blog post when the answer matters.

the question that decides everything

whose screen is being recorded, and who decides that it happens?

row one is where most personal screen memory tools sit. row three, gdpr employee monitoring, is where nearly all the regulatory attention has gone. conflating them produces the two common errors: individuals believing they need a lawful basis to search their own laptop, and employers believing a line in a handbook covers continuous monitoring.

the household exemption, and its limits

gdpr does not apply to processing carried out by a person in the course of a purely personal or household activity.

that exemption sits in article 2, and it is why your photo library is not a regulated database. it plausibly covers a personal screen archive on your own machine, used only by you.

but courts read it narrowly. it stops applying when the processing is connected to professional activity, or when the data reaches other people. gdpr has been in force since 25 may 2018 and applies across all 27 eu member states, so there is no jurisdiction inside the bloc where this analysis differs on the basics.

the practical test is not where the file sits. it is what the recording is for and who else appears in it. a freelancer recording their own screen while working on client accounts has left purely personal territory, which is the situation we work through in ai for consultants.

what counts as personal data on a screen

screen recording personal data is not an edge case, it is the normal case, and this is the part people underestimate.

article 4 defines personal data as any information relating to an identified or identifiable natural person. a screen recording of an ordinary working day contains names in an inbox, faces on a video call, addresses in a crm, salary figures in a spreadsheet and health details in an email a colleague sent about their week.

screen capture is indiscriminate by design. that is its whole value for recall, and it is also why it collides with article 9, which prohibits processing special category data, including health, religious belief, political opinion, trade union membership and sexual orientation, unless a narrow exception applies.

you cannot promise a screen recorder will never capture article 9 data. you can only reduce how much it captures and how long it is kept, which is why exclusion lists and short retention are compliance features rather than conveniences.

the employer case: what is actually required

an employer recording staff screens needs 5 things, not 1.

1. a lawful basis. consent is almost never valid in employment, because it cannot be freely given where refusing has consequences. that leaves legitimate interest, which requires a documented balancing test rather than a line in a handbook.
2. necessity and proportionality. you must show the monitoring achieves the aim and that a less intrusive method would not. "it is useful" is not the standard.
3. transparency. article 5 requires processing to be lawful, fair and transparent. covert monitoring is lawful only in genuinely exceptional cases.
4. a dpia. article 35 requires a dpia where processing is likely to result in high risk, and systematic monitoring of employees is a textbook example. "is screen recording gdpr compliant" has no answer until this document exists.
5. member state employment rules. article 88 lets each country add its own employment specific rules, and several have. germany and france are materially stricter than the baseline, so a policy that clears the bar in ireland can still fail in berlin.

the uk regulator's guidance on monitoring workers is the most readable statement of how this is assessed in practice, and the european data protection board guidelines on video processing carry the same logic across to continuous capture.

gdpr is not the same as recording consent law

these two get merged constantly, and they protect different things.

two party consent statutes, the ones that make recording a phone call risky in california or illinois, govern conversations. gdpr governs personal data. a screen capture with no audio can be entirely fine under wiretapping law and still be a serious gdpr problem, because it is full of other people's information. the reverse is also true.

so a compliant setup has to answer both questions separately. the conversation side is covered in is it legal to record your screen at work, and the audio setting is the one carrying the wiretapping risk.

what it costs to get wrong

the penalty tiers are set in article 83, and monitoring cases land in the higher one.

whichever figure is higher applies, which is why 4% matters far more than the headline number for any company of size. monitoring failures are breaches of lawful basis and transparency, so they sit in the higher tier by default.

the practical exposure is rarely the fine. it is the order to stop processing, plus deleting an archive you had built a workflow around.

the architecture question regulators keep arriving at

where the archive lives changes the analysis more than any policy page does.

if recordings sit on a vendor's servers, that vendor is a processor, you need an article 28 contract, you inherit their breach exposure, and international transfers become your problem. if the archive stays on the device and the vendor never receives it, most of that disappears, because there is no transfer and no third party holding the data.

this is not a theoretical advantage, and the recent record is unusually clear.

rewind promised users their mac archive was private and theirs. then meta acquired the company in december 2025, capture was permanently disabled on december 19, 2025, and users in 7 markets including the eu, uk and south korea lost access immediately, with no export window at all while everyone else got 14 days.

the eu users lost access first precisely because the data was on somebody else's servers. that is the whole argument in what happens to your data when an ai app shuts down.

data minimisation, in bytes

article 5 requires data minimisation, and on a screen archive that principle has an unusually concrete answer.

we measured a real screen memory install across 17 days of capture. it held 26gb. video was roughly 24.6gb, about 95% of the total. the searchable index, the ocr text and its metadata, was 1.4gb, about 5%.

that split maps almost exactly onto risk. the video frames are where other people's faces, inboxes and documents are legible. the index is mostly your own words and the labels around them. so dropping recordings on a short retention clock removes about 95% of the material a regulator would care about, while keeping the 5% that makes the archive useful.

a year of index runs around 20gb against roughly 360gb of video, about 18x more for the part you almost never replay. short video retention plus a long index is both the cheaper design and the more defensible one. the full working is in screen recording storage on a mac.

a practical checklist

6 questions that get you most of the way, in order.

1. whose screen? yours alone, or other people's? this decides whether you are in scope at all.
2. what is it for? purely personal, or connected to professional activity?
3. where does the archive live? your disk, or a vendor's cloud?
4. what can you exclude? an exclusion list for banking, health and hr tools is the cheapest risk reduction available.
5. how long is it kept? short retention is a compliance control, not a storage optimisation.
6. can you delete and export? data subject rights are unworkable if you cannot find or remove one person's data.

if you answer 1 with "mine", 2 with "personal", and 3 with "my disk", you are almost certainly outside the regime. if you answer 1 with "my team's", you need a dpia before you install anything.

where remynd sits

remynd is a personal tool rather than an employee monitoring product, and the distinction is architectural rather than a promise.

the scope, stated exactly: capture is the focused window on your own mac rather than every pixel of every display, ocr runs locally through apple's vision framework, storage stays on your machine, recordings default to 30 days of retention, you can exclude specific apps or sites from capture entirely, and your history is read only everywhere in the app. call transcription runs on device using an mlx speech model on apple silicon. there is no admin console, no fleet dashboard and no way for an employer to read your archive from a server, because there is no server holding it.

that is a different shape from microsoft recall, which is an operating system feature on copilot+ pcs, and from the memory features in chatgpt, claude and gemini, which store what you told the assistant on the provider's own infrastructure. we compare all of them in ai memory is everywhere in 2026.

what it does not do: asking a question sends the retrieved slices to a cloud model, so this is not a claim that nothing ever leaves the machine. it also does not isolate separate clients or projects into separate vaults, which matters if you handle several clients' data on one machine.

if you are evaluating this for a team rather than yourself, start with the dpia. if you are evaluating it for yourself, screen memory is the better starting point.