How to get a clear list of all suppressed alerts for audit?

That's a solid workaround, but you're right, it feels like reconstructing history. Does the `investigationResult` field reliably capture *who* suppressed it and the exact reason? Or is that manual note-taking territory now?

You've hit the nail on the head about reconstructing history. From my own audit runs, the `investigationResult` field is a text blob that *can* contain a manually entered reason, but there's no standardized schema forcing the inclusion of "who" or "why." It's entirely dependent on the analyst's discipline at suppression time, making it unreliable for automated compliance reporting.

A more deterministic, albeit more complex, method is to cross-reference the Workbench alerts with the Audit Logs API, filtering for `eventName` like `WorkbenchAlertSuppressed`. That log entry *will* have the acting user's ID and a timestamp. You then have to join it back to the alert data yourself. It's manual note-taking enforced by API gymnastics, which is frankly disappointing for a platform at this scale.

Yeah, that's exactly what I was worried about. So if I'm understanding right, the `investigationResult` field is basically a free-form comment box? It's only as good as what the person typing remembers to put in.

That seems risky for any real audit. If you're automating reports, you can't count on that field being filled consistently, let alone in a way you can parse.

Following up on user112's point about the Audit Logs API - is that the only guaranteed source for the "who" and "when"? Joining data sounds tough for a beginner like me.

Exactly. That field is a glorified sticky note.

And yes, the Audit Logs API is your only real source for the who and when. The "joining data" problem is the whole point: it's a gap they're making you solve. If you're a beginner, the tough lesson is that you're now building the audit feature they should have sold you. Good luck.

"Building the audit feature they should have sold you" is painfully accurate. This gap pushes the effort and liability onto the team trying to prove compliance, which is a fundamental design flaw for an enterprise tool.

If you go the Audit Logs API route, you're not just joining data. You're also assuming the log retention period for `WorkbenchAlertSuppressed` events outlasts your need for the audit, which isn't a guarantee. You now have a dependency on a separate data lifecycle policy.

It's a brittle solution that treats auditability as an afterthought.

This is a really helpful clarification, thank you. The part about the `investigationResult` being a free-form text blob is exactly the kind of undocumented detail that makes compliance work so difficult.

You mention having to join the data back from the Audit Logs API yourself. I'm curious, in your experience, is there a reliable key field that links a `WorkbenchAlertSuppressed` audit log entry back to a specific alert in the Workbench API? Or do you end up matching on timestamp and user, which seems prone to error if someone suppresses many alerts at once?

The idea of building a joining process around an undocumented relationship between two separate APIs feels like the core of the problem.

Matching on timestamp and user is exactly as error-prone as you think. It falls apart the moment an analyst processes a batch.

The only halfway-reliable key is the alert's `workbenchId`. But here's the kicker: the Audit Logs API response for the suppression event *doesn't include it*. You have to scrape it from the log entry's `description` text field, which is another unstructured blob. So your "joining" process is just parsing another free-text field, hoping the ID format doesn't change.

It's not undocumented, it's deliberately disconnected.

I completely agree about the manual note-taking enforced by API gymnastics being a disappointing state for audit. Your point about cross-referencing the two APIs raises a practical question I've been wondering about.

Given that the `investigationResult` is unstructured and the Audit Logs entry is a separate entity, how do you even begin to structure a reliable join? Are you essentially building a manual lookup process, or have you found a way to script it by scraping a common identifier from the log's description text? It seems like the effort to maintain that script would be as much work as the original manual process.

That's a crucial point about the maintenance burden. In my own attempts, scripting the join by scraping the `workbenchId` from the log description felt like a temporary hack, not a solution. The script would break the moment the log entry's text format changed in an update, and you'd only discover it when your audit report came up empty.

So you're right, it essentially becomes a different kind of manual process: one of constantly monitoring and maintaining the parser, instead of manually recording notes. The liability doesn't disappear; it just shifts from data entry to script reliability.

Given that, is there any consensus on whether it's actually more sustainable to just enforce a strict internal policy where the `investigationResult` field must follow a template, and then live with its limitations? Or does the audit requirement always force you into the API join approach, despite its brittleness?

That maintenance burden is exactly why my team gave up on the API join. We tried the template-in-field approach for a while, and honestly, it works if you have absolute control over your SOC analysts. We used a strict format like `SUPPRESSED_BY: [username]; REASON: [ticket# or standard code]; SCOPE: [permanent/30d]`.

The big caveat is that it only covers your own team's suppressions. It falls apart completely if you inherit an environment where that wasn't the policy, or if you need to audit historical data from before the template was enforced.

So it's sustainable for *ongoing* compliance, but leaves a huge blind spot for any past events. You end up needing both methods: the template for future consistency and a fragile scraper for historical reconstruction.

You've put your finger on the core tradeoff. The template policy creates a clean, machine-readable future state, but it's a form of technical debt for historical data. That gap is itself a compliance risk.

In our case, we found the "blind spot" for inherited environments so problematic that we had to treat the historical reconstruction as a one-time forensic project, not an ongoing process. We used the fragile scraper to build a static lookup table for all pre-policy suppressions, then locked it. Any audit looking at events after the policy date uses the template parse, anything before uses the static lookup. It's administratively messy but at least contains the maintenance burden.

It's a stark example of a tool failing to provide a coherent data model, forcing the user to build their own versioned schema around it.

You've correctly identified the core risk. Treating `investigationResult` as an audit source is a form of data quality gambling; you're betting that human operators will be both diligent and consistent, which rarely holds under pressure.

Regarding your question on the Audit Logs API being the only source for 'who' and 'when', that's correct from the system's perspective. The more subtle problem, though, is that it's a *different temporal system*. The alert has its own timestamps (`createdTime`, `updatedTime`), but the suppression event exists on a separate timeline in the audit log. Joining them requires aligning these two clocks, and any latency between the user action and the log ingestion can introduce mismatches that look like data integrity issues.

For a beginner, the difficulty isn't just the join logic itself, but building the validation to know when your join process is silently failing.

The clock drift isn't just a mismatch, it's an integrity killer. We had join queries fail because the audit log was delayed by several minutes. The join looked broken, but the data was just late.

You need a validation step that flags any alert suppression without a corresponding log entry within a tolerance window, say 10 minutes. Then you have to go manually check those mismatches. It adds another layer of manual review.

So you're not just building a join, you're building an error detection system for the join.

Spot on about the reconstruction being the painful part. The big catch I've found with that API call is it only shows *currently* suppressed alerts. If someone suppresses an alert and then later closes it, that alert disappears from the query results entirely. Your audit trail has a hole unless you're also pulling and archiving those alerts the moment they're suppressed.

So you really need a two-step process: one script to catch and store the suppression when it happens (listening to events or frequent polling), and another to pull the current state. Otherwise, you're only ever seeing a subset of your suppressions.