Privacy Versus Security Modeling

## Two models, two starting questions A security threat model asks *what can go wrong to this system*. A privacy threat model asks *what can go wrong to the person this data is about*. That single change moves both halves of the model: the asset and the adversary. ### The asset moves In a security model the protected asset is the system and the organisation's stake in it - confidentiality, integrity and availability of data the company holds, the money it moves, the service staying up. Harm is measured in what happens to the company. In a privacy model the protected asset is the individual the data describes. Harm is measured in what happens to that person: exposure of something intimate, loss of control over where their data went, an inference drawn about them, a chilling effect on how they behave. A company can suffer no loss at all while a person is harmed - and the model has to be able to represent that. ### The adversary moves Security adversaries sit outside the trust boundary or have escalated across it: an anonymous internet user, a low-privileged tenant reaching another tenant's data, a compromised dependency. A privacy model adds an adversary that every security control is deliberately built to let through - **the operator**. That means the company running the service, staff acting entirely within their granted permissions, contracted processors and vendors, and a future version of the company after a strategy change or an acquisition. ### Why a security design pass will not raise it A design pass walks flows and stores asking whether each is authenticated and each access authorised. In the therapy example every answer is yes: transport is encrypted, storage is encrypted, the support console is behind SSO with per-access audit logging. Nothing is unauthorised, so nothing is reported. The privacy finding lives entirely inside what is *authorised*: support engineers can read transcript bodies, and bodies are retained indefinitely. ### The controls are different in kind Security controls mostly make access harder. Privacy controls mostly make the data smaller, shorter-lived, or narrower in permitted use: - **Data minimisation** - do not collect the field, or collect a coarser version of it. - **Storage limitation** - keep it for the shortest time the purpose needs; drop bodies while keeping the operational metadata. - **Purpose limitation** - bind data to the purpose it was collected for, so a new use is a decision, not a query. - **De-identification and aggregation** - publish counts and answers rather than rows. - **Scope and time bounding of operator access** - redacted-by-default views, expiring grants, break-glass with a recorded reason and a notification to the person. | Question | Security model | Privacy model | |---|---|---| | Who is protected | the system and its owner | the person the data describes | | From whom | unauthorised or escalated parties | anyone processing the data, the operator included | | What counts as harm | breach of confidentiality, integrity, availability | exposure, loss of control, unwanted inference | | Typical control | authenticate, authorise, encrypt, monitor | collect less, keep less, use narrower, aggregate | | A pass means | no unauthorised path found | no unnecessary data, access or retention found | ### Doing the pass Take the same diagram you already drew. For every store and every flow add two questions the security pass never asks: *is every field here necessary for the stated purpose*, and *which humans inside the operator can see it, under what trigger*. On the therapy service that yields three concrete findings - bodies retained forever, standing read access for the whole support rota, and a debugging workflow that never actually needed the text - and three concrete changes: strip bodies from the debugging path, shorten body retention, convert standing access into reason-bound, time-limited, user-visible break-glass. The same pass applied to a school-issued laptop's monitoring agent yields the same shape of answer: the adversaries are the institution and its managed-service vendor, and the mitigation is narrowing what the agent may see and when, not hardening the agent. ### Where the two models genuinely conflict They are not always aligned. Non-repudiation and audit want long retention; storage limitation wants short. Abuse detection wants IP addresses and device fingerprints; minimisation wants neither. Fraud investigation wants raw history. Resolve these explicitly: name the security need, the minimum data and minimum window it truly needs, and record the decision - otherwise the maximum-retention default silently wins. ### Keep the vocabulary straight The *threat* is that operator staff read intimate transcripts with no need to. The *vulnerability* is standing read access plus unbounded retention. The *risk* is the rated consequence for the person and the business. The *control* is minimisation plus break-glass. Privacy findings get waved away most often when they are stated as values rather than as a threat with a named actor, a named path and a named person who is harmed.