A controller answers a data-portability request by sending only an unreadable screenshot PDF of a GUI. What format expectation does that response fail when portability applies?
Select an answer to reveal the explanation.
Short Explanation
A screenshot PDF of a GUI is like handing someone a photo of a spreadsheet instead of the spreadsheet file—they can squint at it, but they cannot really move or reuse it. Portability wants structured, commonly used, machine-readable data. Pretty pictures of screens do not cut it.
Full Explanation
Where portability applies, personal data must be provided in a structured, commonly used, and machine-readable format so the data subject can reuse them or transmit them to another controller. Answering with only an unreadable screenshot PDF of a GUI fails that format expectation: humans may squint at pixels, but machines and receiving controllers cannot reliably reuse the data. Portability’s purpose is practical mobility of personal data, not a souvenir image of a screen that locks the person into manual retyping.
Portability does not always require handwritten paper forms stamped by a notary. Visibility to a human eye does not make any screenshot compliant with the machine-readable standard. Portability also requires more than confirmation that data exist; an export—or transmission—of the portable dataset is the operational point of the right when its conditions are met.
Exam caveat: machine-readable and commonly used beats “you can see it if you zoom.” Operational check: offer CSV, JSON, or similar structured exports for qualifying datasets, test imports into common tools, support direct transmission where feasible, and explain any lawful limits clearly. Digital public services should enable residents to take their data with them in usable form when portability conditions apply—supporting autonomy rather than locking people into unreadable PDFs that frustrate switching and civic digital choice.