List every alert type you produce, and write beside each one a primary owner, a backup, a response target and an escalation step. Keep it as a single table in the repository. An alert without an owner is a notification, not a control.
What the map is
An ownership map is a short document that answers one question for every signal: who acts on this? It covers dependency alerts, secret findings, failed gate checks, anomalous logins, scanner failures and anything else that can reach a person.
Without one, signals go to whoever happens to be in a channel. That works until the person is on leave, or until two teams each assume the other will deal with it. See an alert nobody acts on is not a control.
Template
| Signal | Primary owner | Backup | Target to acknowledge | Escalates to | Channel |
|---|---|---|---|---|---|
| Dependency alert, critical, reachable | Owning service team | Team lead | 1 business day | Security lead | Ticket plus chat |
| Dependency alert, other | Owning service team | Team lead | Weekly review | Team lead | Digest |
| Secret found in repository | Committer and team | Security | Same day | Security lead | Chat plus ticket |
| Release gate failure | Author | Reviewer | Before merge | Team lead | Pull request |
| Scanner or log source silent | Platform team | Security | 1 business day | Platform lead | Chat |
| Silence older than 7 days | Silence owner | Team lead | Weekly review | Security lead | Digest |
The targets above are examples. Choose numbers your team can meet, since a target nobody meets teaches people to ignore targets.
Steps to build it
- Inventory the signals. Check each tool, each pipeline and each log based alert, and list what reaches a person.
- For each, name who can actually fix the cause. That is the owner, even if it is not the person who is easiest to message.
- Pick a named backup. A team name alone is not enough when only one person is on call.
- Set an acknowledgement target and an escalation step that fires without anyone having to remember it.
- Pick one primary channel per signal. See where should dependency alerts go.
- Test it. Send a harmless test signal through each route and see who responds, and how quickly.
- Review every quarter, and after a reorganization.
Where it goes wrong
Owners that are mailing lists. Backups who do not know they are backups. Escalations that point at a person who has left. A map that is written once and never opened again.
Make it visible
Put the table where people look: the repository readme for the service, the on call handbook, the incident channel topic. Check each time a team changes shape. A map that is only known to its author does not help during an incident.
Quick check
Who should own a dependency alert?
The team that owns the service and can change its dependencies, with the team lead as backup.
How often should I review the map?
Quarterly, and whenever teams or tools change.
Safeguard's policies, gates and compliance evidence automation can record owners and decisions for findings. Try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
