A security risk should be owned by the person who controls the asset or process at risk and has authority over its budget, usually a business or engineering leader, not the security team. Security advises and tracks. The owner decides whether to treat, share or accept, and answers for the outcome.
Risk owner, control owner, and risk manager
Three roles often get mixed up:
- Risk owner. Accountable for the risk and the decision about it.
- Control owner. Responsible for operating a specific control, such as access reviews.
- Risk manager or security lead. Maintains the register, challenges ratings, and reports.
One person can hold more than one role on a small team, but write it down so each duty has a name.
Why not security
If the security team owns every risk, the business never has to choose. Security cannot spend another team's budget, change another team's roadmap, or accept a revenue impact. Ownership without authority produces risks that sit for months.
NIST IR 8286A describes risk guidance, appetite and tolerance as inputs that stakeholders set, and risk registers feed an enterprise register. That framing assumes business leaders take part in deciding what is acceptable.
Setting acceptance authority
Create a simple table in your policy that links rating to approver. For example:
- Low and moderate risks: the team lead or product owner.
- High risks: a director or head of function.
- Very high risks: the executive sponsor, with the board informed.
Adjust the levels to your size. The principle is that more serious risks go higher.
Keep the table consistent with your risk appetite statement, and with your exception process so a temporary deviation does not become a quiet permanent acceptance.
What an owner does
- Reviews the rating and the scenario for accuracy.
- Chooses a response.
- Commits resources or accepts the risk in writing.
- Reviews progress on a set schedule.
- Escalates when plans slip or circumstances change.
Handling disputes
Sometimes an owner disputes a rating. Ask them to state which factor they disagree with and what evidence they have. If they still disagree, record both views and let the acceptance authority decide. Disagreement documented is better than silent downgrading.
Handling orphan risks
Cross-cutting risks, such as a shared identity system, may not have an obvious owner. Pick the executive who would face the consequences first, and name them. An unowned risk is a risk nobody will treat.
Write it into policy
Put the owner definition, the acceptance table and the escalation route in one short policy page. Review it with the executive team once a year. New owners then know what they are signing up for, and nobody learns their duties during an incident.
Quick check
Can a contractor own a risk?
Ownership should sit with an employee who has authority and accountability. A contractor can own a control task but not accept risk for the company.
Should accepted risks expire?
Yes. Set a review date, because threats, systems and costs change.
Sources
Last reviewed: 19 October 2026.
