A data subject demands portability of inferred credit scores created solely by the controller’s algorithms. How does portability typically treat such inferred data?
Select an answer to reveal the explanation.
Short Explanation
Portability is mostly about packing up what you brought to the relationship—not every score the controller dreamed up about you. Inferences can matter for access and other rights, but they are not automatically in the portability suitcase. Know provided versus derived.
Full Explanation
Portability centres on personal data provided by the data subject under qualifying conditions—not every inferred or derived field the controller creates through its own algorithms. A demand to port inferred credit scores typically falls outside that core, even though access or other rights may still shed light on profiling. Controllers should explain the distinction rather than dump or refuse everything indiscriminately.
Not all inferences must be portable in machine-readable form on demand. Inferred scores are not made portable merely by being stored in a paper credit file. Portability is not categorically unavailable to all financial-services data; the limiting factors are legal conditions, not industry labels alone.
Exam caveat: provided vs inferred is a classic portability discriminator. Operational check: classify fields as provided, observed, or inferred; export qualifying provided data in structured form; address inferred data through access/transparency pathways as appropriate. Lenders and civic scoring programmes should be clear with people about what can move with them and what reflects the organisation’s own analysis—honesty supports trust even when portability is limited.