Keep a new security policy in warn mode until you have read a sample of its results, tuned the wrong ones, and every owner has a clear way to fix or request an exception. For many teams that means two to four weeks and at least one full release cycle. Then enforce in small steps, not all at once.
Why warn first
A policy that blocks on day one will block the wrong things. Warn mode shows what would have happened without costing anyone a release. It is also the cheapest way to find gaps in ownership, such as repositories with no owner, before those gaps become urgent.
Exit criteria for warn mode
Do not leave warn mode on a date alone. Leave it when these are true:
- You have reviewed a sample of results by hand and know the false positive rate
- The worst rules have been tuned or removed
- Every repository in scope has an owner
- An exception path exists and has been tested
- Developers have seen the policy text and the timeline
- You know how many pull requests would be blocked on day one
If the last number is large, enforce on a subset first.
A staged path
| Stage | What happens | Typical length |
|---|---|---|
| 1. Observe | Run silently, collect results | One to two weeks |
| 2. Warn | Show results on pull requests, block nothing | Two to four weeks |
| 3. Enforce for new code | Block only findings introduced by the change | Ongoing |
| 4. Enforce on a pilot group | Willing teams get the full rule | Two to four weeks |
| 5. Enforce broadly | Everyone, with exceptions tracked | Ongoing |
| 6. Tighten | Lower thresholds one notch at a time | Quarterly |
What to measure at each stage
- Number of pull requests that would have been or were blocked
- Share of blocks that developers disputed
- Median time to fix a block
- Exceptions requested and granted
- Overrides used
If disputes exceed what you can handle, go back a stage.
Communicate each change
State the date, the scope and the contact before each step. A short note two weeks ahead does more than a perfect policy. Keep the old stage available for rollback for the first week of each new one.
Signs it is time to move on
Developers ask when the rule will become blocking because they want the protection, or findings produced are routinely fixed without prompting. Signs to pause: bypass rates rise, developers move code around the check, or support questions pile up.
Rolling back
Plan for it. Make switching a rule back to warn mode a quick, logged change, and agree who may do it. A policy you can back out of safely is one you can afford to tighten.
Quick check
Can some rules enforce immediately?
Yes. Rules with near zero false positives, such as a confirmed live secret, can enforce early. Start with those.
What if a team keeps asking for exceptions?
Look at the pattern. It may mean the rule is wrong, the fix is too hard, or the team needs help. Do not simply approve every request.
Safeguard policies, gates and guardrails let you decide which findings block and which only report. A free scan gives you data to test a policy against.
Last reviewed: 19 October 2026.
