To merge two dependency policies, list every rule from both side by side, decide one outcome for each (keep, tighten, or drop), name one owner, and roll the result out in warn mode before you enforce it. Do not simply declare the parent company's document the winner and move on.
Why a straight swap usually fails
Two companies rarely write the same rules. One may block copyleft licenses outright, the other may allow them for internal tools. One may fix critical vulnerabilities in a week, the other in a month. If you replace one policy with the other overnight, the acquired team hits blocks it has never seen, builds break, and people learn to route around the process.
The goal is a single policy that both teams can follow and that still answers the questions your customers and auditors ask. NIST describes the Secure Software Development Framework as a core set of high-level practices that can be integrated into each software development life cycle. That framing helps here: the practices stay stable while the wording and thresholds get reconciled.
Step 1: Put both policies in one table
Build a sheet with one row per rule and a column for each company. Typical rows: allowed license types, vulnerability severity thresholds, remediation deadlines, who approves a new dependency, how exceptions work, pinning and lockfile rules, allowed registries, and what happens on a failed check.
If a rule exists in only one policy, mark the other cell as "silent". Silence is a decision point, not a gap to ignore.
Step 2: Choose an outcome per rule
For each row, pick one of four outcomes.
| Situation | Usual outcome |
|---|---|
| Both rules match | Keep as is |
| One rule is stricter and cheap to meet | Adopt the stricter rule |
| One rule is stricter but expensive to meet today | Adopt it with a dated transition |
| Rules conflict for a real business reason | Escalate to the owner and write down why |
Record the reason next to each decision. Six months later, someone will ask why the deadline is what it is.
Step 3: Name one owner and one exception path
A merged policy with two owners is two policies. Pick a single accountable person or group, and a single place where exceptions are requested and recorded. If you want help choosing, see who owns the dependency policy after a consolidation.
Step 4: Dry run before you enforce
Run the draft rules against both codebases in report only mode. You are looking for surprises: how many repositories would fail today, and which rule causes most of the failures. If one rule blocks half of one team's repositories, that is a transition problem, and you can solve it with a schedule rather than by weakening the rule forever. A longer walkthrough is in move a security policy from warn mode to enforce mode.
Step 5: Publish, version, and retire the old documents
Publish the merged policy with a version number and a date. Keep the old documents archived, not deleted, because past audits and customer answers refer to them.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a policy rule turns into a pass or block on a pull request.
Safeguard can enforce the merged rules as policies and gates across both teams' repositories, and its free scan at https://gold.safeguard.sh/scan gives you a quick read on a codebase before you decide.
Quick check
Should the stricter policy always win?
No. Adopt the stricter rule when meeting it is cheap, and phase it in when it is not. Strict rules that nobody can meet get bypassed.
How long should merging take?
Drafting can take days. Enforcement should follow a dry run and a transition period you set per rule, so plan in weeks rather than a single cutover day.
Sources
Last reviewed: 19 October 2026.
