A people-risk owner demands an ATT&CK technique ID for a permitted insider export. What do you tell them?

## Why this conversation happens The person in front of you owns a people-risk process, and their template has a mandatory technique field. They are not being obtuse. Identifiers are how their peers compare one situation to another, how their reporting line expects things to be labelled, and often how their template was designed by somebody who assumed every adverse event has one. They came for a string, and the honest answer is that no true one exists. ## What you are refusing, and why An ATT&CK identifier asserts a specific thing: *a behaviour matching this entry has been observed in published adversary activity.* For an export performed through the person's own granted role, every plausible candidate asserts something false or empty. A cloud-storage read technique is true of the export and equally true of the analytics job that reads the same data lawfully every night — an identifier that fits both discriminates nothing. A valid-accounts technique claims the actor was operating through credentials that were not theirs, which is a factual claim about an account takeover that did not occur. The catalogue has no field for authorisation because its subject is adversary behaviour, and adversaries are assumed to be acting without permission. When permission is the *only* thing wrong, the model runs out of representation. ## The three costs of just filling the field **False precision.** A string that looks like evidence of analysis becomes the summary of an event that was analysed correctly and then mislabelled. **Downstream reinterpretation.** Nobody reads a stored identifier with the caveats you held in your head. A year on, a set of these rows is read as a set of technical intrusion behaviours, and any claim built on that set is wrong. **The wrong remedy.** A technique identifier invites the question "which technical control stops that technique?", and for a permitted action the answer is none — the action is indistinguishable from the work the role exists to do. The controls that actually remove it are authorisation and process ones: scope bulk read out of the standing role, make export a separately approved and time-bound grant, split the person who requests from the person who releases, and cut standing rights at resignation rather than at last day. Handing over an identifier quietly redirects the remedy budget away from all of them. ## What to offer instead **A plain description in the same slot.** Actor position (a rightful holder of a granted role), mechanism (the platform's own bulk-read operation), asset, and the crucial sentence: the permission was real and the reason was not. **A partial mapping, clearly bounded.** If the person did something technical beyond exercising the grant — copied the extract onward to personal storage, archived it to removable media, disabled an expiry — map *that step* and say in writing that the mapping covers only that step. This is often the compromise that lands, because it gives them a true identifier for a true fact. **A change to the template.** Ask for the field to accept "no applicable technique" with a mandatory free-text reason. This is the real ask, and it is an organisational one: you are telling the owner of a process that their form encodes an assumption — every adverse event is a technical adversary behaviour — that is wrong for an entire class of the events they exist to handle. Name the class: permitted actions, and objectives reached with no technical step at all. ## When they refuse They may have no authority to change the template, or a reporting obligation that will not bend this quarter. Then take the least-damaging version: the nearest identifier accompanied, in the same field, by an explicit qualifier that the action was inside granted permission and the technique describes only the mechanism. Say plainly that you expect to re-explain this every time the row is read, and put the same sentence anywhere the row is summarised. Track it, and bring the template change back with two or three more examples behind it — a pattern argues better than a principle. ## What makes this a judgement rather than a rule There is no correct answer independent of who you are talking to. Refusing outright protects accuracy and can cost you the working relationship with the function that handles the *only* control class that actually removes this behaviour. Complying protects the relationship and corrupts a shared vocabulary that other people rely on. The defensible position is to refuse the false claim, supply everything true that you can, and make the template — not the fact — the thing you argue about.