Versioning, rollback and environment promotion for rules

Git gives you a history of the file. The SIEM holds the copy that runs, and some platforms keep their own revisions too. Elastic, Google, Sentinel and Splunk document rule history or audit. No platform read documents a full dev, staging and production promotion flow for rules, so you build that.

When a rule change goes wrong at 2 a.m., two questions matter. What changed, and how fast can you put it back? Git answers the first for the file. It answers the second only if the running copy matches the file. This guide covers where history lives, how rollback works, and how to promote a rule through environments without a platform feature that does not exist.

Two histories exist and they can disagree

The repo holds one history. The SIEM holds another: the live rule, plus whatever edits someone made in the console. If anyone can edit in the UI, the repo and the SIEM drift apart, and a rollback in git restores a state that was never running.

The fix is policy before tooling. Pick the repo as the source of truth, and make console edits either impossible or detected. Microsoft Sentinel's repositories docs describe the repository as the source of truth for connected content, and its SentinelAudit table records who changed which property from which value (Sentinel custom content CI/CD, read 2026-11-04). That gives you the detection half: a console edit shows up in the audit log with before and after values. Rollback in Sentinel is a git revert, not a product button.

Platform revisions help but do not replace git

Some platforms keep rule revisions natively. Check the details, because they differ.

Google Security Operations creates a new revision whenever rule text changes, and its Rules API exposes listRevisions with etag concurrency control, so two writers cannot silently overwrite each other (Google rules API reference, read 2026-11-04). The product also documents live and alerting states, archive rules and view rule versions (Google view rule versions, read 2026-11-03).

Elastic documents a History view in Elastic Stack 9.5 and later that shows a timeline, compares revisions and restores earlier states (Elastic manage detection rules, read 2026-11-04). Rules are also TOML files in the detection-rules repo, so both histories exist. If you are on a version before 9.5, you do not have the History view.

Splunk Enterprise Security documents detection versioning and review and deprecation of detections, and contentctl marks content production, experimental or deprecated (Splunk detections docs, read 2026-11-03). ESCU ships as numbered releases, with v6.9.2 shown on research.splunk.com on the read date (Splunk research, read 2026-11-03).

Panther keeps content in git and the detections docs describe no version history or rollback inside the product (Panther detections docs, read 2026-11-04). That is a clean model if you hold the line on git. It leaves rollback entirely to your pipeline.

Anvilogic's product page claims version history, diffs and rollback for detections (Anvilogic detection engineering page, read 2026-11-03). It is a vendor claim from a product page, with no commands shown and docs behind a login. Sekoia documents rule states Active, Scheduled for Deprecation and Deprecated with a valid-until date and notifications (Sekoia rules catalog, read 2026-11-03), which is lifecycle rather than history.

Rollback is a deploy, so test it like one

Rolling back is a pipeline run, not an undo. Revert the commit, let the pipeline validate and deploy the previous version. This works if the pipeline is fast and if the deploy step is idempotent.

Practice it. Once a quarter, deploy a harmless change to a test rule, then revert it through the pipeline and time it. If it takes 40 minutes because someone has to approve a ticket, you want to know before the incident. The 40 minutes is an illustration. Your number will differ.

For platforms with native revisions, know which route is faster. Restoring a revision in Elastic's History view is quick for one rule. Reverting a commit is better when a change touched 30 rules at once.

Promote through environments with status, not hope

A staged flow needs a place to stand between a pull request and production. None of the platforms read documents a complete dev to staging to production promotion for rules. Sentinel says connections map repository content to workspaces and track changed files with smart deployments, without a staged flow. Elastic's reference lists pre-production testing and managing multiple rule sets, without a promotion flow. Anvilogic describes deploying everywhere from one workflow across SIEMs, which is multi-platform deploy, not staged environments.

So you build stages from what exists. Three patterns work.

Branch per environment. Merge to a staging branch deploys to a staging workspace. Merge to main deploys to production. Simple, and it makes the staging workspace real.

Status field. Use the rule's lifecycle status. Sigma defines stable, test, experimental, deprecated and unsupported (Sigma specification, read 2026-11-03). Deploy experimental rules disabled or to a low severity queue, and promote by changing the status in a pull request.

Shadow mode. Deploy the rule with alerting off, and read its matches for a week before turning alerts on. Where a platform has Limited or Paused states, as Google documents, use them.

Whichever you choose, record the promotion in the pull request, with the replay numbers.

Plan for platform moves

Platforms change under you. Microsoft's docs state that Sentinel is supported only in the Defender portal after 2027-03-31 (Sentinel automation docs, read 2026-11-03). Splunk's contentctl README says future investment is shifting to Detection Studio (read 2026-11-03). Panther announced an agreed acquisition by Databricks on 2026-06-16, and one investor profile says it closed on 2026-08-03, which no second source confirms (Security Boulevard, read 2026-11-03). Keep rules in a portable layout so a tool change moves files, not knowledge.

Checklist

The repo is the source of truth, and the team agreed on it in writing.
Console edits are blocked, or a job flags any rule that differs from the repo.
You know whether your platform keeps native revisions and which version has them.
Rollback is a pipeline run, and you timed one this quarter.
Every rule has a status: stable, test, experimental or deprecated.
New rules start in staging or shadow mode and are promoted by pull request.
Promotion records the replay numbers.
Deprecated rules carry a date and a removal date.
The layout keeps rules portable if the platform changes.