Set a grace period per rule instead of one for the whole policy. Make it short where the risk is severe and the change is easy, and longer where meeting the rule needs a refactor. Give each period an end date, an owner, and a progress check, and announce the end date in advance.
Why one blanket grace period fails
A single "ninety days to comply" sounds fair. In practice, some rules take an afternoon to meet and others take a quarter. A blanket period lets the easy rules slide until the last week, and it is too short for the hard ones, which then end in a pile of exceptions.
Sort rules into three groups
Switch on now. Rules that cost almost nothing to meet and prevent real harm. Examples: blocking a package that is known malicious, or requiring a lockfile where one is already generated.
Warn, then enforce. Rules most repositories already meet, with a few stragglers. Run in warn mode first, publish the list of failing repositories, and set a near end date.
Phased. Rules that need real work, such as moving every service off an unsupported framework. Break these into milestones and give each repository its own date.
Choosing a length
There is no correct number, but you can reason about it. Consider:
- How many repositories fail today, from a dry run
- How much effort a typical fix takes
- How severe the risk is while the rule is not enforced
- Whether a release freeze or busy period sits inside the window
A useful test: if the number of failing repositories is not shrinking by the midpoint, either the period is too short or the rule needs a better path to compliance, such as a template or a fix pull request.
Make the period visible
Publish a table with the rule, the mode (warn or enforce), the date it changes, and the owner. Teams cope with a hard date they were told about. They resent a surprise.
| Rule | Mode now | Enforced from | Owner |
|---|---|---|---|
| Example: lockfile required | Enforce | Now | Platform |
| Example: license tiers | Warn | Date set by owner | Legal and platform |
| Example: framework upgrade | Phased by repository | Per repository | Team leads |
Ending a grace period
On the end date, switch the mode, not the date. Extensions should be rare and go through the exception path, with a reason. If you extend everyone, you have changed the policy without saying so.
For a deeper look at the switch itself, read move a security policy from warn mode to enforce mode and how to evaluate security policies and gates before you roll them out.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what the gate reports on a pull request, the same view a team sees during warn mode.
Safeguard policies and gates can be set per rule, so one rule can warn while another enforces.
Quick check
Should the grace period be the same for both merged teams?
Not necessarily. The team that already meets a rule needs none, while the other may need a schedule.
What if a team misses its date?
Use the exception path with a reason and a new expiry, and track repeated misses as a signal about the rule.
Last reviewed: 19 October 2026.
