After a consolidation, one named person or small group should own the dependency policy, with engineering leadership as the approver for changes and security as an advisor. Many owners means many versions of the policy. Write the roles down, including who may grant exceptions and who is informed.
What ownership actually covers
Owning a policy is not writing it once. It means answering for four things: the text is current, the rules are enforced, exceptions are tracked, and changes are announced. If nobody holds those four, the policy drifts and the two old documents quietly come back.
A simple role split
| Role | Responsibility |
|---|---|
| Policy owner | Keeps the text current, runs reviews, arbitrates conflicts |
| Approver | Signs off on changes that affect delivery speed or cost |
| Security advisor | Provides risk input, checks that rules match threats |
| Engineering leads | Apply the policy in their teams, request exceptions |
| Legal or compliance | Reviews license and contract related rules |
| Everyone else | Is informed of changes before they take effect |
In a small company the same person may fill several rows. That is fine, as long as the roles are written down and the owner is a person, not a department alias that nobody reads.
Where the owner should sit
Teams argue about this. A few patterns:
- Security owns it. Strong on risk, but rules can drift away from how developers work.
- Platform or developer experience owns it. Strong on adoption and enforcement in pipelines, but needs security input on thresholds.
- A small council. Works when both merged organizations need a voice, but needs a chair with a tie breaking vote.
Whichever you choose, the owner needs access to the tooling that enforces the policy. A policy owner who cannot see gate results is guessing.
Handle the awkward first months
During a merger, the owner will receive requests from both sides: "our old rule was looser, please keep it". Decide ahead of time how to respond. A reasonable approach is a short intake form, a decision within a set number of working days, and a public log of decisions. See who should own a security tool consolidation project for the related tooling question.
Set a review rhythm
Put a recurring review on the calendar, for example every quarter for the first year, then twice a year. Each review checks exception counts, gate overrides, and whether any rule routinely forces a workaround. Related: policy review dates and the out of date policy finding.
Write the handover
When the owner changes, hand over the open exceptions, the pending decisions, and the list of tools that enforce the rules. A policy with a good owner and no handover becomes a policy with no owner in one resignation.
Safeguard gives the owner one place to see policies, gates, and their results across repositories, which makes the review rhythm easier to keep.
Quick check
Can two teams co-own the policy?
They can share input, but one person must have the final say, otherwise conflicts do not get settled.
Should the owner be the most senior person?
Not necessarily. Pick someone with time, access to the enforcement tools, and the standing to say no.
Last reviewed: 19 October 2026.
