A central security team wrote every policy rule and cannot maintain them. How do you re-home ownership?

## Why the central-authorship model runs out A small security team writes the first rules because they are the only people who know what is required. That scales to a few dozen rules. Past that, the team is the bottleneck for every false positive, every threshold argument and every new resource type, and the estate learns two habits: route around the gate, or stop trusting it. The rules keep running; nobody maintains them. That is the state the question describes, and it is an organisational problem with a technical surface, not the reverse. ## Separate three roles that got merged **Requirement.** Someone states that production data stores must be recoverable within a window. This is a risk statement and it can legitimately stay with security, or with whoever owns the obligation. **Rule ownership.** Someone owns the encoding of that requirement: the threshold, which resource types it matches, its fixtures, and the judgment call when a team says it is wrong. This is what should move, and it should move to the domain closest to the resource — the database platform team for backup retention, the observability team for log retention. **Operation.** Someone runs the engine and the gate. That stays with the platform team and is unaffected by re-homing. A candidate who collapses these will propose either "security owns everything" (the current failure) or "teams own everything" (which quietly deletes requirements nobody wanted to keep). ## What must travel with a rule for a transfer to be real - **Authority to change it.** An owner who may not alter the threshold is a name in a file; they will forward every complaint back to security, and you have added a hop rather than an owner. This is the single most common way re-homing fails. - **The reason it exists**, expressed as the obligation rather than the number, so the new owner can tell when a change is a tuning decision and when it is a breach of something they may not touch. - **The fixtures**, including every false positive ever reported, so they inherit the accumulated knowledge and not just the code. - **Current denial data.** How often it fires, on which teams, and how many of those became rule changes. A team accepting a rule blind is accepting an unknown workload; a team that sees it denies twice a week and has three open disputes is making a real decision. - **The failure message**, since that is what carries their name into other teams' builds from the day of transfer. ## What stays centrally owned Rules encoding an obligation nobody in the company may relax — a contractual commitment, a regulatory requirement, a customer-specific control. Handing those to a delivery team is nominal ownership, because the one action ownership implies (changing the rule) is forbidden. Keep them with a security owner and require a second approver for any loosening. Also keep cross-cutting rules with no single natural domain, at least until one exists, and be honest about that rather than pretending an arbitrary team owns them. ## The forcing function Re-homing by request fails: teams have no incentive to accept work. Two mechanisms do work. First, make unowned rules visibly temporary. The rule repository's CI flags rules whose owner entry does not resolve to a live team, and unclaimed rules are demoted from blocking to reporting, then removed, on a published schedule. It is uncomfortable, and that is the point: it forces the conversation about whether anybody actually wants this control, instead of leaving builds blocked by a rule with no answerable owner. Second, tie ownership to the pain. The team whose builds a rule most often blocks, and who understands the resource, is usually the team who should own it — they have the strongest incentive to make it precise, and the domain knowledge to do so. The obvious objection is that they will simply relax it; that is what the requirement statement and the second-approver rule on loosening are for. ## Knowing whether ownership is real Ownership shows up in behaviour, not in files. Look for: changes to the rule merged by its owning team; the owner's review appearing on its diffs; disputed denials ending in a fixture and a rule change rather than in a chat thread; and a stated response window that is actually met. An owner entry that has never produced a commit is an assertion, not a fact. ## The costs you accept Distributed ownership means rules drift in style and quality, so you pay for a light central review — a small group that reviews new rules for message quality, metadata and over-blocking without holding a veto on the requirement. It also means uneven maturity: some teams will run their rules well and some will let them rot, and you will need the same expiry mechanism to catch the second group. Both are better than the state you started in, where every rule was owned in name by people who could not maintain any of them.