Driving data collected for insurance pricing is now wanted by the claims team - how do you evaluate that reuse?

## The threat with no confidentiality violation A telematics programme collects speed, braking, cornering and trip timing from drivers who signed up to get a cheaper premium. Months later the claims team asks for query access to that history so it can dispute a payout after an accident. Run a conventional security pass over the request and everything passes. The data does not leave the organisation. Both teams are inside the same trust boundary. The claims analysts authenticate, they are authorised, the query is logged. No confidentiality, integrity or availability property is violated. There is no vulnerability to point at, so a design review produces nothing. The privacy model produces a threat immediately, because it asks a different question: what happens to the *person*. A driver handed over granular behavioural data in exchange for a price. It is now evidence against them in a dispute over their own money. The adversary is the operator's second legitimate use of its own data; the assets at stake are personal data and the customer's payout. ## Purpose limitation, stated precisely Purpose limitation is the principle that data collected for a specified purpose should not be further processed in a way incompatible with that purpose. Two things follow that people routinely get wrong: 1. **It is not the same as access control.** Access control asks *may this identity read this record*. Purpose limitation asks *may this record be used for this end at all*. A perfectly-scoped role grant answers the first question and is silent on the second. 2. **Not every secondary use is forbidden.** The test is compatibility with the original purpose, judged on how related the uses are, what the person was told and would reasonably expect, the sensitivity of the data, and the consequences for them. Fraud investigation of the very policy the data prices sits closer to the original purpose than routinely arming claims adjusters with driving history. (The legal machinery around notices, lawful bases and consent is a separate discipline; as a design reviewer your job is to surface the decision, name who owns it, and make the outcome enforceable in the architecture.) ## How to run the evaluation **Establish the original purpose in writing.** Not what the data could support - what drivers were actually told. If the answer is "nobody knows", that is finding number one, and it applies to every future request. **Characterise the new use.** Which fields, which population, which decisions, and what happens to the person as a result. A use that only ever helps the customer is a different proposition from one that reduces a payout. **Look for the less invasive form.** This is the highest-value move and it is usually skipped. Does claims need trip-level telematics, or a single risk indicator? Could the input be an event window around the incident rather than the full history? Could the same need be met by data collected for claims, with its own notice? Minimising the *reuse* is as legitimate a control as minimising the collection. **Decide, then enforce it structurally.** A policy promise degrades the moment the team reorganises. Structural enforcement looks like: separate purpose-tagged stores rather than one warehouse everyone queries; access grants issued against a declared purpose and expiring; retention driven by the purpose's lifetime, so the pricing feed ages out and cannot be mined later; derived, coarser datasets published for uses that do not need rows; and a periodic review of who holds which purpose-scoped grant. **Write the decision down.** Whatever the answer, the reasoning is the artefact - it is what stops the same request being re-litigated by a new manager, and what makes an audit tractable. ## The organisational call The judgment a lead actually owns is not this one request; it is the mechanism. Ad-hoc adjudication means the answer depends on who is asked and how loudly the requester escalates, and purpose creep wins by attrition. A standing secondary-use gate - a short, fast, documented review triggered whenever a dataset is used for a purpose outside the one it was collected for - trades a little analytics velocity for a bounded blast radius when a dataset turns out to be repurposable in ways nobody sanctioned. The honest cost is real: the data team will experience it as friction, and a gate that takes weeks will simply be routed around by copying the data. Make it days, make the default answer for closely-compatible uses a fast yes, and reserve real scrutiny for uses that act *against* the person the data describes. That asymmetry - fast for uses that serve the customer, slow for uses that oppose them - is the design principle worth defending in the interview. ## Vocabulary check The *threat* is data given for pricing being used to contest that person's claim. The *vulnerability* is a single undifferentiated store with purpose-blind access grants. The *risk* is the rated harm to the customer plus the regulatory and trust exposure. The *controls* are purpose tagging, expiring per-purpose grants, purpose-bound retention, and a review gate.