When two companies' dependency rules conflict, sort each conflict by risk to customers and cost to change. High risk and low cost means adopt the stricter rule now. High risk and high cost means adopt it on a dated schedule. Low risk means pick the simpler rule and move on.
What counts as a conflict
A conflict is any case where the same event gets two different answers. A package with a weak license is allowed in one company and blocked in the other. A high severity finding must be fixed in seven days under one policy and thirty under the other. One team may pull from the public registry directly while the other only uses an internal mirror.
Silence also counts. If one policy has no rule on install scripts and the other bans them, you have a conflict that only shows up when a build fails.
The matrix
Score each conflict twice, high or low, then read the cell.
| Low cost to change | High cost to change | |
|---|---|---|
| High risk | Adopt the stricter rule now | Adopt the stricter rule with a dated schedule and an interim control |
| Low risk | Pick the simpler rule | Keep both for a while, converge at next review |
Risk here means what happens to your customers or your obligations if the weaker rule stays. Cost means engineering time, tooling change, and disruption to the team that has to move.
Worked examples
These are illustrations, not recommendations for your numbers.
Remediation deadlines differ. Risk is high because exploitable flaws stay open longer. Cost is moderate because the slower team needs process change, not rewrites. Outcome: adopt the shorter deadline for critical findings on a staged schedule, and keep the longer deadline for lower severities until the team has caught up.
License allow lists differ. Risk depends on how the software is distributed. If one company ships software to customers and the other runs internal services only, the rules may be legitimately different. Outcome: define license tiers by how the code is used, not by company. Related reading: a three tier open source license policy.
Registry rules differ. Risk is high if one team pulls straight from a public source with no review. Cost is moderate. Outcome: move the loose team behind the same mirror or proxy that the stricter team uses, and set a date.
Escalation rules
Some conflicts cannot be settled by a matrix, such as a customer contract that names a specific control. Write an escalation path: who decides, within how many days, and where the decision is recorded. Without that, conflicts get settled by whoever argues longest.
Record every decision
For each conflict, store the two original rules, the chosen outcome, the reason, and a review date. This turns a messy merger into a changelog you can show an auditor. See also policy exceptions in code, not in chat.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped by severity, which is the input for any deadline rule.
Safeguard policies and gates can hold the agreed rules in one place, so both teams are checked against the same outcome.
Quick check
Can two rules live side by side for a while?
Yes, if the low risk cell applies and you set a review date. Without a date, the split becomes permanent.
Who breaks a tie?
The named policy owner, with the reason written down. Do not leave ties to the loudest team.
Last reviewed: 19 October 2026.
