There is a conversation that happens in almost every organization I have ever encountered, usually in a conference room, usually after something has gone sideways, backward and upside down. Someone of extreme importance asks who owns a particular system, process, or risk. There is almost always a pause… that lasts just long enough to become uncomfortable. Sometimes like a sitcom, you’ll then get several people trying to speak at once, and comically (not at the time) each pointing to a slightly different person/team. The meeting ends with an action item to clarify ownership (sure are other action items…but not for this post), which itself gets assigned to someone who does not own it… nothing really changes and the cycle continues.
This is not a story about a single incident or a cautionary tale from a breach post-mortem, I (and you) have seen this too many times. This is the operating condition of most modern enterprises, unless audit is in the room…then this never happens. The gap between who “owns” something and who is actually accountable for it is not a mistake. I tend to think, somewhere along the way, is a feature….a unspoken organizational coping mechanism that lets everyone feel responsible without anyone being responsible.
In most organizations, “ownership” means your name is on a spreadsheet. That spreadsheet lives in a SharePoint folder that was last updated within a year (during the audit), and the person whose name appears in the “owner” column may have left the company, changed roles, never told, or simply forgotten that the spreadsheet exists. Asset ownership, system ownership, data ownership…these are concepts organizations love to document and loathe to update or enforce.
The security implications here are not subtle, because when no one really owns an asset, no one is really responsible for patching it, monitoring it, classifying the data it holds, or making the call when something about it looks wrong. The asset responsibility drifts, accumulates technical debt, adds undocumented dependencies, and eventually a vulnerability that someone will have to explain to the board. At that point, ownership suddenly becomes very easy to establish, it belongs to whatever team or whoever is holding the update ticket.
Ownership is generally a label, but the accountability piece is what happens when that label is tested. That distinction matters enormously but also gets collapsed constantly in organizations. You can assign ownership in an afternoon over a cup of coffee, but building genuine accountability, the kind where someone actually feels the weight of a risk decision, that takes intentional governance design, clear authority, and a leadership culture willing to follow through when things go wrong. Most organizations have the spreadsheet, and very few have the culture.
I can hear you scream at that monitor (I can’t really…I just have an active imagination) “The RACI matrix was invented to solve exactly this problem”. Side note: For those unfamiliar, it is a grid where every task or decision gets assigned someone who is Responsible, Accountable, Consulted, or Informed. In theory, it eliminates this ambiguity that I’m talking about. I feel like though in practice, it creates a document that everyone agrees to during a workshop or meeting and no one references again until the next audit (if ever).
The failure piece is not the tool… it’s the mistaken belief that defining accountability in a document constitutes accountability in practice. Real accountability requires two things that a RACI matrix cannot provide. First, the authority to act and second the consequences for inaction. Without those two things, the “A” in the grid is just another label on another spreadsheet.
Security governance can also suffer from this problem as well. Policies get written, controls get documented, and ownership gets assigned, but the authority to actually enforce any of it is fuzzy at best. A CISO can write a patching policy that says critical vulnerabilities must be remediated within 30 days. What happens on day 31 when a business unit has not patched because their application team said it would break something? You going to turn the metric red on another spreadsheet. If the CISO has no authority to escalate (with teeth), the policy isn’t a policy it’s an advisory. The organization is putting on governance theater…all the costumes and set pieces but, none of the plot.
Executive leadership in some companies tend to be surprised by this dynamic during incident response, which is perhaps the most expensive and worse time to learn about it. The conversation that begins with “why wasn’t this patched” rarely ends with a satisfying answer, because the honest answer is that the accountability structure was never designed to make patching anyone who can actually do something’s actual problem.
Organizational psychology (I hate this term exists) has a name for what happens when responsibility is broadly shared…diffusion. The more people who are nominally responsible for something, the less likely any individual is to act on it. The bystander effect plays out in corporate governance with remarkable consistency. When everyone owns the risk, no one loses sleep over it. Compare this to why they recommend during an emergency you point and assign someone to do something (like call 911) versus just asking broadly for someone to do it.
I think that cloud infrastructure has made this worse in ways that are still being fully absorbed. In traditional environments, the boundaries of ownership were reasonably… well physical. A server sat somewhere, and there was someone there who managed it. In modern hybrid and cloud environments, assets spin up and down, teams provision resources without informing IT, and the concept of a “system owner” can become genuinely philosophical. For example who owns a serverless function that was deployed by a developer, runs on infrastructure the security team does not manage, processes data that the legal team hasn’t classified, and touches a third-party API that procurement negotiated? The honest answer is that ownership is ambiguous by design, because the model was optimized for speed and cost, not governance clarity.
None of this is a condemnation of cloud or modern development practices. I love these systems, but it is an observation that the governance models organizations inherited from a simpler infrastructure era have and have not updated to kept pace, and the gap is a security and governance gap. Fixing this does not require a new framework or another governance workshop (I think we have enough of those), but it requires some organizational honesty and a few durable commitments.
The first is to stop confusing documentation with reality, the ownership records spreadsheet, RACI matrices (matixs?, matrixii?), and data classification inventories are useful when they reflect how the organization actually operates (not ideally…really). They are just useless noise when they reflect how the organization wished it operated. Keeping these things current is work…unglamorous, ongoing, detail-oriented work. Organizations that treat it as a one time compliance deliverable will keep discovering the gap in the worst possible moments.
The second is to tie accountability to authority. If a system owner is expected to make security decisions about their system, accepting risks, driving remediation, escalating to leadership, then they need the organizational standing and autonomy to do it. Security cannot function as a team that issues mandates and then politely asks business units to please comply when they feel like it. Authority and accountability have to travel together or neither works.
The third is to make risk visible to the people who own it. One of the persistent dysfunctions in security programs is that risk information lives with the security team while the decisions live with business leaders who never see the data. A business unit director who does not know that their systems are running three years behind on patches has no reason to prioritize fixing it (or usually even the knowledge on how to). Information is the requirement for accountability. If business owners are not receiving regular, intelligible reporting on the security posture of what they own, the governance model has a structural flaw regardless of what the RACI says.
The fourth (and the one executives most reliably resist) is consequences. I am not talking about punitive, reflexive consequences designed to assign blame after incidents, but consequences as a systemic feature of the authority…meaningful escalation paths, visible risk acceptance by named decision makers, and leadership that actually follows through when accountability obligations are not met. Organizations where nothing ever happens when security commitments are ignored have not built accountability. They have built a suggestion system with a compliance aesthetic.
I said at the begining that almost every organization quietly struggles with this, and I want to be precise about the word “quietly.” This is not something that shows up in board presentations or strategic plans. Organizations do not announce that their ownership model is decorative. The gap lives in the spaces between org chart lines, in the meeting where nobody volunteers to take the action item, in the audit finding that gets accepted as a known risk for the fourth consecutive year.
It is quiet because naming it directly is uncomfortable. Saying “we have assigned ownership of this without giving anyone the authority or incentive to actually do anything about it” is an indictment of the governance decisions that leadership made, often deliberately, to avoid the friction that real accountability creates. Real accountability means sometimes the answer is no. It means sometimes a project is delayed because a security gate was not met. It means sometimes someone has a difficult conversation that they would prefer not to have.
Most organizations have decided (sometimes implicitly, sometimes accidentally) that the friction of genuine accountability costs more in the short term than the alternative. That calculation changes reliably and expensively after an incident. The question for every leadership team is whether they want to get ahead of that math or wait to do it under pressure.
The conference room pause… that moment where nobody knows who owns the thing…is not a failure of memory. It is a signal that the organization telling you, clearly, that the accountability structure was never built to survive contact with reality. The solution is not to assign ownership faster, it should be to build a model where ownership means something, where accountability follows authority, and where the gap between the two is treated as the operational risk that it genuinely is…in an incident the spreadsheet is not enough, and honestly it never was.