A works-council agreement bars per-employee endpoint telemetry outside an approved case. How do you run a hunt that needs it?

## The constraint is operational, not merely legal Many organisations, particularly in jurisdictions with strong employee-representation structures, operate under a standing agreement with a works council or equivalent body that defines what the employer may monitor. A typical shape: estate-wide security detections are permitted because they evaluate behaviour and surface only matches; **per-person telemetry** — reconstructing one named employee's activity — is permitted only inside a defined case with recorded approval, and sometimes only with the representative notified. That is a hard boundary on what a hunt may look at, and treating it as an obstacle to route around is the answer that fails the interview. The productive framing is that it constrains the *shape* of the search, and most hunts can be reshaped. ## Reduce the hypothesis first A hunt hypothesis is usually about a behaviour: "has any host run a scripting interpreter spawned from an office document since Tuesday?", "is any endpoint making outbound connections to newly registered domains at a fixed interval?". The person is incidental. So: - **Pivot to the host, not the human.** Endpoint process telemetry keyed on hostname answers most behavioural hypotheses without naming anyone. - **Box the fields.** Process creation and parent-child lineage is a different intrusion from browsing history or document titles. Ask for the fields the behaviour lives in. - **Box the time.** Six hours around a suspected event, not ninety days of everyone's day. - **Return matches, not streams.** A detection that outputs only records matching the behaviour reveals far less than a query that returns a person's whole timeline for a human to read. - **Aggregate first.** "How many hosts show this pattern?" is often enough to kill or confirm a hypothesis; only a non-zero answer justifies going further. ## Pseudonymisation with rehydration The strongest pattern here: identifiers (usernames, hostnames, mailbox addresses, device ids) are replaced with stable tokens at or near ingest, and the mapping is held separately with its own access control. The hunt runs entirely on tokens — correlation still works because the tokens are stable — and reveals a real identity only when a hit is significant enough to justify an approval request. Be precise about what this is and is not. Pseudonymisation is **reversible by design**; that is the whole point, and it is why the mapping store is the sensitive asset and needs the two-person approval and its own audit. Irreversible hashing would break the case when you actually need to act. And pseudonymisation is not encryption at rest, which protects against a different party entirely. ## Break-glass, if the agreement defines one A well-drafted agreement anticipates that a serious, live investigation may need per-person data before the ordinary process can run. That route typically requires: a named approver, notification to the employee representative within a fixed period, a narrow default scope, and a retrospective review. Use it as designed, and expect to justify why reduction was not possible. ## The question going unanswered is a real outcome This is the part candidates avoid saying out loud. Sometimes the honest answer is: under the governance we operate, this hunt cannot be run, and we do not know. That is a correct result. What makes it professional rather than negligent is the record you leave: - the hypothesis, and why it mattered; - the data that would have tested it; - why the reduced form was insufficient; - the residual risk, in terms the business understands; - the ask for the next revision of the agreement. A blind spot that is written down, owned and re-argued each cycle is governance working. A blind spot nobody recorded is a surprise waiting for an incident review. ## The direction of the claim, which is the trap A constrained search that returns nothing proves nothing about the estate. It proves that within those fields, that window and that population, nothing matched. Reporting "we hunted for this and found it clean" after a heavily reduced search overstates the result, and it is the specific error that turns a governance constraint into a false assurance. Say what you searched and what the negative therefore covers. ## Talking to the representative If you end up in the room with the employee representative, what they need is not technical detail. They need: the purpose in one sentence, the scope and why it is the minimum, who will see the output, how long it is kept, what happens if the person turns out to be innocent, and evidence that the analysts' own access is itself audited. That last point does more to win the argument than any explanation of the hunt, because it answers the question actually being asked: who watches you.