To merge two exception registers, combine them into one format, keep every original approval date and approver, re-check each entry against the merged policy, and give every surviving exception an owner and an expiry date. Entries nobody can justify should lapse on a stated date.
Why exceptions deserve their own step
Exceptions are where a policy is quietly weakened. After a merger you inherit two sets of them, approved by people under different rules, some by people who have left. Importing them as they are would carry old decisions into a new policy without anyone checking they still make sense.
Step 1: Pick one record format
Use the same fields for every entry. A workable set:
- The package, version range, or rule the exception covers
- The repository or product it applies to
- The reason, in plain words
- The compensating control, if any
- Who approved it and when
- The owner who will remove it
- The expiry date
If one old register has no expiry field, add it now and leave the value blank for the review step.
Step 2: Import without rewriting history
Copy the original approval date and approver into the new register, even when the approver is gone. You are not erasing the past, you are keeping an honest trail. Add a column for the date of import and the source register.
Step 3: Re-validate each entry
Walk through every entry with three questions.
- Does the merged policy still have the rule this exception relates to? If the rule was dropped, the exception is moot.
- Is the stated reason still true? A fix may now exist, or the component may be gone.
- Is the compensating control still in place?
Mark each as keep, renew with a new expiry, or close.
| Result | Action |
|---|---|
| Rule dropped | Close, note why |
| Reason no longer true | Close and fix the underlying issue |
| Still valid | Renew with a new owner and expiry |
| Cannot be justified | Set a short, announced expiry |
Step 4: Set the new approval path
Decide who may approve new exceptions in the merged organization, and for how long. Many teams tier this: a team lead for short, low risk exceptions, and a security owner for anything touching high severity findings. See who approves open source policy exceptions by company size.
Step 5: Keep it in code where you can
An exception recorded in a chat message is invisible to the gate and to the auditor. Where your tooling allows it, store exceptions as reviewed files in the repository, so they are versioned and visible in the same place as the rule. More in policy exceptions in code, not in chat.
Watch the numbers
After the merge, track how many exceptions are open, how many are past expiry, and how many were renewed more than once. A growing renewal count points to a rule that does not fit reality.
Safeguard policies and gates support exception handling alongside the rules they apply to, so approvals sit next to enforcement.
Quick check
Can we just drop old exceptions?
Only after review. Dropping them silently can break builds and erase the record of why something was allowed.
What if the original approver left?
Keep their name and date in the record, and assign a current owner who is responsible for the entry from now on.
Last reviewed: 19 October 2026.
