A 30-day plan to move an existing rule set into git

Most teams do not start with a clean repo. They start with 600 rules in a console, some written by people who left, some copied from a vendor pack, some nobody can explain. The goal of this plan is not perfection. It is a state where every rule is a file, every change is a pull request, and the console is read only. Thirty days is tight and realistic for a team of two or three if you resist rewriting rules.

The numbers in the plan, such as 600 rules and 20 priority rules, are planning sizes from practice. Replace them with your own counts.

Week one: inventory and export, and rewrite nothing

Day one is a count. How many rules, how many enabled, how many alerted in the last 90 days, who owns each. A spreadsheet is fine. The inventory tells you where the effort goes.

Then export. Every platform here documents a route.

Elastic's detection-rules CLI documents kibana import-rules and export-rules (detection-rules CLI reference, read 2026-11-03), and the repo lists import-rules-to-repo and export-rules-from-repo as well (Elastic detection-rules, read 2026-11-04).

Microsoft Sentinel's Alert Rules REST API documents Create Or Update, Delete, Get and List, so a script can list every analytics rule and write each to a file (Sentinel Alert Rules API, read 2026-11-03).

Google Security Operations documents a Rules API and Unified Rules API with search, list and batch modify of live, alerting and archive states (Google Unified Rules API, read 2026-11-03). The community repo's content manager CLI manages rules through the REST API (chronicle detection-rules README, read 2026-11-03).

Splunk's contentctl keeps content as YAML in a repo layout and documents init and new to scaffold it (contentctl user guide, read 2026-11-03). Rules created in the console need converting into that layout by hand or by script.

Panther's panther_analysis_tool uploads and deletes through the API, so content already in a repo has a direct path (Panther Analysis Tool, read 2026-11-03).

If a vendor writes or manages the rules, ask for the export before week two. Hunters says customers are not required to build detections themselves and documents no repo sync (read 2026-11-04). Mate Security documents no export, API or repo for its detections on the pages read and ranks eleventh of fourteen on the proposed scores. If your rules live behind one of these, week one includes a written request for an export format.

By day seven you have one file per rule in a repo, committed as is. Do not edit them. The first commit is the baseline.

Week two: add structure and a validation gate

Create the repo layout: a folder per platform or per log source, one rule per file, and a short README. Add an owner field and a status field to each rule file. Sigma defines stable, test, experimental, deprecated and unsupported, and borrowing that vocabulary saves an argument (Sigma specification, read 2026-11-03).

Add CI that runs validation on every pull request. Use the platform's own validator: validate-all for Elastic, contentctl validate for Splunk, panther_analysis_tool validate for Panther. For Sentinel, a connected repository generates a workflow, and the docs note a limit of five connections per workspace (Sentinel repositories docs, read 2026-11-04). Plan your repo layout around that limit.

Turn on branch protection. One reviewer, passing checks, no direct pushes to main. Do not deploy from CI yet. This week CI only reads.

Expect the validator to fail on rules nobody has touched in years. Fix the ones that matter and mark the rest status deprecated with a removal date. Do not spend the week fixing dead rules.

Week three: tests and a health baseline

Tests first for priority rules. Pick the 20 rules you trust most or that cover your top techniques. Write one alerting event and one near miss for each. Panther documents test events with an expected alert outcome and sets no minimum (Panther testing docs, read 2026-11-03). Twenty rules with tests beat 600 without.

Then a health baseline. Run the queries your platform documents: the SentinelHealth table in Sentinel, the Rule Monitoring tab in Elastic, the Rule Observability dashboard in Google. Record which rules failed in the last 30 days, which fired zero times, and which fired the most. Save it as a file in the repo with the date. This is your starting score.

The baseline tells you which rules to fix first and gives you a number to improve. Without it, you cannot say the migration made anything better.

Week four: switch deploys to the pipeline and drill rollback

Now deploy from CI. Start with the lowest risk rules: disabled, test, or low severity. Run the deploy job on merge to main, using a scoped API token stored as a pipeline secret. Add a post-deploy check that the rule exists and its last run did not fail.

Then lock the console. Remove edit rights for everyone except a break-glass account. If you cannot remove them, add a nightly job that compares the repo to the SIEM and opens a ticket for any rule that differs.

Finish with a rollback drill. Change a test rule, deploy it, revert the commit and time the recovery. Write the time in the README. Platforms with native history, such as Elastic's History view from version 9.5 or Google's rule revisions, give you a second route, and you should know both.

What to leave for month two

Leave the rewrite of old rules, full ATT&CK coverage measurement, replay in CI and the drift checks. They matter. They are also where migrations stall. Ship the pipeline first and improve the rules inside it.

Checklist

• Day 1: counted rules, enabled rules, alerted rules and owners.
• Day 7: every rule exported to a file and committed unedited.
• Day 10: repo layout, owner field and status field agreed.
• Day 14: validation runs in CI and branch protection is on.
• Day 21: 20 priority rules have tests, and a dated health baseline is saved.
• Day 25: deploy from main runs through a scoped token with a post-deploy check.
• Day 28: console edits blocked or flagged nightly.
• Day 30: rollback drill done and the time written down.
• Any vendor-managed rules have a written export request.