Why does a SOC audit its own analysts' SIEM search queries?
answer
- The search bar is a privilege
- Analysts are a monitored population too
- Who searched which identifier, when
- The case reference supplies the purpose
- Stored where analysts cannot edit it
basics
~20 sReading employee telemetry is itself a privileged act. The query audit records who searched which identifier, when, and under which case reference, so analyst misuse is detectable and the SOC's own access to people's data is evidenced.
solid answer
~40 sA SOC's search bar reaches mailboxes, endpoints, sign-ins and web history for named people, so running a query exercises privilege the way an admin login does. The query audit is the control over it: for every search it records the account, the timestamp, the index, the query text, the time range and the case reference the search ran under. That buys deterrence and detection of misuse — the analyst looking up an ex-partner, a colleague or an executive is a real, recurring pattern; defensibility, so an employee or representative asking who read their data gets evidence; and protection for the analyst, since a query tied to an open case shows they were working. The audit must live where SOC staff cannot edit it, and be reviewed outside the SOC's reporting line.
code
json · 10 lines{
"event": "search.executed",
"time": "2026-03-11T02:41:07Z",
"actor": "analyst.jdoe",
"index": "mail_audit",
"query": "recipient:[email protected] OR sender:[email protected]",
"time_range": "-90d..now",
"case_ref": null,
"results_returned": 412
}go deeper
Be ready to say plainly that running a search over a named employee is a privileged act, and that your own queries are recorded with your account, the identifiers and the case you ran them under.
Explain the fields that make the record useful — actor, index, query, time range, case reference — and why a null case reference is the pattern that gets reviewed rather than an automatic finding.
Show the failure modes: shared accounts, unaudited export and direct-query paths, and an audit index the SOC itself administers. Say who reviews it and on what cadence.
Own the argument that the SOC's access power needs the same accountability it demands of admins, and be able to defend the SOC's record of access to an employee representative or an auditor.
## The SOC as a subject, not only an operator Almost everything else on this topic treats the SOC as the party doing the watching. The query audit inverts that: the analysts themselves become a monitored population, and their searches become a log source like any other. The reason is simply the reach of the tooling. A tier-1 analyst with a normal console can typically pull a named person's mailbox activity, their endpoint process telemetry, their sign-in history, their proxy or DNS records and their file access. That is a more intimate view of an employee's day than their own manager has, it is available in seconds, and it leaves no trace on the subject's side. An organisation that hands out that capability without a record of how it is used has created an unaudited surveillance power. ## What the record contains A usable query-audit entry captures, at minimum: | Field | Why it matters | | --- | --- | | Actor account | Who ran it — and it must be a named human account, not a shared service account | | Timestamp | When, including out-of-hours patterns | | Index or source | Mail audit, endpoint telemetry, sign-in logs, HR data | | Query text | Which identifiers were named | | Time range | A 6-hour window versus 90 days is a completely different intrusion into someone's life | | Case reference | The stated purpose — the field that turns a search into an authorised act | | Result count | Whether anything was returned | The case reference is the important one. Nothing in the query itself supplies a purpose; the link to an open, approved case does. A search with a null case reference is not automatically misconduct, but it is the pattern worth asking about. ## What the record proves, and what it does not A query-audit entry proves that **an account submitted that query at that time**. It does not prove a human was at the keyboard, that the analyst read or understood the results, that the results were exported, or that the purpose was legitimate. It equally does not prove the reverse: an analyst who ran no query may still have seen the data on a dashboard, in an alert payload, or in a screenshot a colleague pasted into a chat. That direction matters when the audit is used as evidence in a disciplinary case. "The account ran a 90-day mailbox search for a named colleague with no case reference" is a defensible, factual claim. "The analyst read their colleague's email" is a stronger claim that the record alone does not carry. ## Detections written over it Because it is just another log source, you can write detections on it. Common ones: - a search naming the analyst's own identifiers (self-lookup); - searches for identifiers with no linked open case; - lookups of a watchlist of executives, board members, HR staff or high-profile employees; - a sudden rise in the number of distinct subjects one analyst queried in a day; - unusually broad time ranges on person-scoped searches; - bulk exports, which frequently escape the audit entirely. These are low-volume and high-consequence, so they are usually reviewed by a person rather than paged. ## The failure modes that make the control fake 1. **Shared accounts.** If four analysts share one console login, the audit names nobody. 2. **Unaudited paths.** An analyst who queries the underlying data store directly, opens a notebook against the raw index, or pulls a CSV export may bypass the audited interface completely. Every read path needs to be audited, or the audited one becomes optional. 3. **The subject administers the audit.** If SOC staff can delete or edit the query-audit index, it cannot be used against them. Ship it to an append-only store outside their administrative control. 4. **Nobody reviews it.** An audit no one reads deters only people who believe someone reads it. Assign the review to a function outside the SOC's line — internal audit, privacy, or compliance. 5. **No case reference field.** Without a purpose binding, every entry looks equally justified and the audit answers no question. ## Why interviewers ask it It is a fast test of whether a candidate sees the SOC as accountable rather than merely trusted. Someone who answers "so we can catch analysts snooping" has half of it; the stronger answer adds that it makes the organisation's *own* access to employee data evidenced, which is what you need when an employee, an employee representative or an auditor asks the question.
- What detections would you write over the analyst query audit?Self-lookups where an analyst names their own identifiers; searches with no linked open case reference; queries naming executives, HR staff or board members from a watchlist; a jump in distinct subjects queried per analyst per day; unusually wide time ranges on a person-scoped search; and bulk exports. Volumes are low and consequences are personal, so these go to a human reviewer outside the SOC line rather than to the pager.
- The query audit shows an analyst searched a colleague's mailbox with no case reference. What does that record establish?That the analyst's account submitted that query, against that index, over that time range, at that time, with no case linked. It does not establish that a human was at the keyboard, that the results were read or exported, or that there was no legitimate reason. It is enough to open a question, and it is the factual claim you can defend; anything stronger needs corroboration such as endpoint activity, exports or an interview.
- Where should the query-audit log live, and who reads it?In a store that SOC analysts and SOC platform admins cannot alter or delete — append-only, ideally shipped outside the team's administrative control — because otherwise the subject of a future case administers their own evidence. Review belongs to a function outside the SOC's reporting line, typically internal audit, privacy or compliance, on a defined cadence rather than only when someone complains.
A hospital logs which staff opened which patient record, not because clinicians are suspected, but because opening a record is an act with a subject who deserves an answer about who read it.
saying these in an interview costs you the question
- Assumes analysts are trusted so no audit is needed
- Treats a query record as proof the analyst read the data
- Stores the query audit in an index analysts administer
- Omits the case reference, so no search has a stated purpose
- Ignores export and direct-database read paths that bypass the audit