Who Owns the Risk?

Ask three people in your company who owns cyber risk and you will usually get three different answers.

Security says the business owns it. The business says Security owns it. GRC says it is whoever is named on the risk register, which often turns out to be whoever had time to fill in the spreadsheet.

That confusion is not a wording problem. It is why risks sit open for years, why exceptions never expire, and why nobody can tell the board who actually decided to live with a gap.

Here is a clearer model that works for mid-sized companies without enterprise theater.

Ownership Is About Decisions, Not Job Titles

A risk owner is the person who can decide what to do about a material exposure. They understand the business consequence. They can fund remediation or accept residual risk within delegated limits. They escalate when the exposure sits above that limit.

They do not have to run the firewall, write the policy, or take the tickets. Ownership is decision rights. Execution can live elsewhere.

If the named "owner" cannot approve budget, stop a launch, or accept residual risk in writing, they are a coordinator, not an owner.

What Each Role Actually Owns

Use this split. It maps cleanly to how most growing companies already work.

The board owns risk appetite, oversight, and approval of major trade-offs. They should know which services cannot fail, which residual risks were accepted above threshold, and how long recovery would take for a critical outage. They do not pick endpoint tools.

The CEO and executive team own execution and resourcing within that appetite. When product wants to ship before a control is ready, or keep a legacy platform alive, that is an executive decision, not a Security ticket.

Business and product owners own the risks created by their services, data, and decisions. The VP whose product stores customer data owns the exposure that comes with that product. Security can advise. GRC can document. The VP still owns the call.

The CISO (or security lead) owns the security program, the quality of risk information, control effectiveness, and an independent escalation path. They identify, analyze, recommend, and escalate. They do not silently inherit every business consequence labeled "cyber."

GRC / second line owns the risk-management process: methodology, register, assessments, treatment tracking, and reporting. Facilitating the process is not the same as owning the exposure.

Internal audit (when you have it) owns independent assurance that the model above actually operates.

When those lines blur, accountability disappears. When Security "owns" every cyber risk, the business stops making hard trade-offs and Security becomes the dumping ground for decisions it cannot fund.

Why Mid-Sized Companies Get This Wrong

Three patterns show up again and again.

1. The CISO is the default owner on every row. Convenient for the register. Useless for remediation. The person who can actually change the system or accept the gap is not in the room.

2. GRC owns the risk because GRC wrote it down. Process ownership gets confused with risk ownership. Your register looks complete. Your backlog does not move.

3. Shared ownership with no named individual. "Security and Engineering co-own this" means nobody owns the deadline. Name one accountable person. Others can support.

PCI programs make this especially visible. Control owners, ISAs, merchants, and service providers all have defined roles, but risk acceptance still needs a human with authority. A clean RACI on paper does not help if the only person who can say "we accept this for 90 days" is never named.

How to Assign Ownership in Practice

Start with a short set of rules and apply them to your material risks, not every scanner finding.

1. Ask what business objective is affected. Revenue service, regulated data, customer trust, uptime commitment. Follow that objective to its accountable leader.
2. Confirm they can decide. Can they fund treatment? Can they accept residual risk within a written limit? Can they escalate above that limit? If not, go one level up.
3. Separate owner from operator. The owner decides. Security, IT, or Engineering may execute the control. Write both names if you need to, but keep one accountable owner.
4. Set acceptance thresholds. Define who can accept what, for how long, and when it must go to an exec or the board. An open-ended exception is not acceptance. It is neglect with a form attached.
5. Review on a calendar. Material risks and accepted residuals get a quarterly look with the owner present. If the owner has left the company, reassign before the next audit, not during it.

For a lean team, you do not need a 40-page risk policy to do this. You need a register with real names, a one-page escalation matrix, and a review meeting that actually happens.

What Good Evidence Looks Like

Auditors and customers care less about the theory and more about whether ownership operates.

Keep evidence that shows:

• A named owner on every material risk and critical service
• Written risk acceptances with scope, expiry, and approver
• Escalations that reached the right level when thresholds were crossed
• Quarterly review notes with owners in attendance (or a documented substitute)
• Clear separation between process facilitation (GRC) and decision ownership (business)

In a GRC platform like episki, that means risk records tied to owners, acceptance workflows with expiry, and treatment tasks that do not orphan when someone changes teams. Spreadsheet owners who left six months ago are how findings become surprises.

A Simple Test

Pick your top five open risks. For each one, answer:

• Who can accept this residual risk in writing today?
• Who can fund the fix without asking three other people?
• Whose name is on the register, and do those two answers match?

If the answers diverge, you do not have ownership. You have a label.

So, Who Owns the Risk?

The business leader accountable for the objective, service, or data at stake. Security owns the program and the quality of the information. GRC owns the process. The board owns appetite and oversight.

When those roles are clear, risk conversations get shorter, acceptances get honest, and remediation stops waiting on a team that was never funded to fix it.

If your register still lists Security as the owner of everything cyber, start reassigning. The first meeting will be uncomfortable. The next audit will be quieter.

Key Takeaways

• Risk ownership follows decision rights and business consequence, not the Security org chart
• Business and product leaders own risks created by their services; Security advises and escalates
• GRC owns the process and the register, not the exposure itself
• Name one accountable owner per material risk, with written acceptance limits and expiry
• Review owners and accepted residuals on a real calendar, and keep the evidence

Is risk ownership still a label on a spreadsheet, or a real decision with a named owner? episki helps mid-sized teams attach owners, acceptance workflows with expiry, and treatment tasks to the same records they use for evidence. Get started free