Admin Audit Log - Who Changed What

Burrow records every configuration change made through the dashboard, with timestamps, the analyst who made the change, and a before/after diff. The History page is your audit trail for "who disabled the ransomware rule and when?" or "who added this user to the entity exception list?" - both during an incident and during external compliance reviews.

What gets logged

Every action that changes Burrow's behaviour is recorded:

• Disposition changes - when an analyst marks an alert Real / Not real / Maybe.
• Posture changes - when an admin switches between Permissive / Relaxed / Balanced / Strict / Paranoid.
• Per-rule overrides - when an admin sets a custom threshold for a specific rule.
• Rule enable / disable - when an admin adds or removes a rule from the Disabled rules list.
• Custom rule additions / edits - when an admin defines or modifies a custom detection rule.
• Entity exception additions / removals - when an admin silences or unsilences a user pattern.
• Sensitive-site approvals - when an admin approves an auto-suggested sensitive site, or pins a manual one.
• Internal-domain pins / excludes - when an admin overrides the auto-learner.
• Notification settings - when an admin adds / removes email recipients or changes the minimum severity gate.
• Partner and untrusted-list updates - when an admin adds, removes or re-levels an External Partner or Untrusted domain.
• Suggestion actions - when an admin applies or dismisses a tuning suggestion.
• Label-rule edits - when an admin changes a per-label rule.

Each entry records the time, the acting analyst, the action, its target, a before / after diff, and the client IP.

Everything now lands in one trail (2026-08-14). Suggestion-panel and label-rule actions used to be written to a second journal that the History page never read - so they were recorded, but invisible here. They are now written through the same path as everything else, and the older entries were migrated in, so History is a complete account of admin activity rather than most of it.

Read-only views (opening an alert, running a Hunt search, browsing the dashboard) are not logged. Only changes are.

Opening the History page

1. Open the Burrow dashboard.
2. Click History in the left navigation.

The page lists actions in reverse-chronological order. Each row shows:

• Timestamp - when the change happened.
• Analyst (the By column) - the signed-in operator who made the change, taken from their dashboard login (their email / UPN).
• Action - short label (disposition, rule edit, exception add, posture change, etc.).
• Target - what was changed (an alert key, a rule name, an exception ID, etc.).
• Diff - click to expand and see the before / after state of the changed field.

The signed-in operator is now recorded on every dismissal, disposition, case action, and configuration change (2026-07-23). Because attribution is captured at the moment of the action, a few older rows may show a generic placeholder rather than a name - those predate this change, or came from a request made outside a logged-in session; they keep whatever was recorded at the time.

Filtering

The filter bar at the top of the page:

• Action type - narrow to one kind of change (e.g. just disposition decisions, or just posture changes).
• Analyst - narrow to one operator (useful for shift-by-shift review or off-boarding audits).
• Time range - last 24 hours, last week, last month, or custom.

Pagination at the bottom of the table for navigating older entries.

Common questions the History page answers

"Who turned off the ransomware rule?"

• Filter Action type to "rule disable" and review. Each entry has the analyst's identity and timestamp.

"What did our SOC team triage during last week's incident?"

• Filter Action type to "disposition" and time range to the incident window. Each entry shows which alert was triaged, what the analyst decided, and when.

"Who added user X to the exception list?"

• Filter Action type to "exception add" and search for the user pattern. The matching entry shows who added the rule, when, and what reason text they provided.

"Has anyone changed the posture in the last quarter?"

• Filter Action type to "posture change" and time range to the quarter. Each entry shows the analyst, the old posture, and the new posture.

Undoing from the History page

The History page is not purely a record - it is also where you undo things.

• Reopen - every dismissal row carries a Reopen button. Reopening returns the alert to the Active and Open tabs immediately, even if the AI had judged it not real - an operator reopening something is an override, and the operator wins. It also cancels that dismissal's contribution to any learned quieting, so a mistaken dismissal does not go on teaching Burrow to stay quiet.
• Recent bulk actions - every bulk dismissal is recorded as a single batch: a multi-select Dismiss, a Suppress matching, or a Dismiss ALL. Each batch has one-click Undo, which reopens the alerts it dismissed. This is the answer to "I just bulk-dismissed a pile of alerts by mistake."

The log itself is still append-only

Undo does not erase history. An undo adds entries rather than removing them, so the record of what was dismissed, by whom, and that it was later reopened all survives. No entry is ever deleted from the dashboard. That is what keeps the log usable as defensible evidence in HR, legal, or external audit settings - the ability to reverse an action and the ability to hide one are different things, and only the first is offered.

If you need a CSV of a filtered History view for an audit binder, raise a support ticket.

Pairs well with the suppression journal

The History page tells you what configuration changed and who changed it. The suppression journal tells you what alerts were skipped and why.

Together they answer "is anything happening in our tenant that the SOC team chose to hide from us?" - the answer being "everything they chose not to email, plus every operator action they took, is logged here."

See also

• Exporting the suppression journal - the suppression-side audit trail.
• Dispositions - what each disposition click writes to History.
• Entity exceptions - config changes that show up here.

Need help? support@smikar.com.