Who Owns What: Mapping Security Responsibilities Across Your Organization

Most security ownership disputes aren’t really about security. They’re about who has to do work that nobody budgeted for, who gets blamed when something goes wrong, and who has the authority to make decisions in someone else’s domain.

The CDM doesn’t resolve organizational politics. Nothing does. But it gives you a concrete surface to have ownership conversations on, which is more than most frameworks offer. Instead of arguing about whether “network security” belongs to IT or to the security team, you can point at specific cells and ask specific questions: who owns Networks/Identify? Who owns Networks/Protect? Who responds when we see something in Networks/Detect?

Those are answerable questions. The abstract jurisdiction fight is not.

The natural ownership pattern

Yu’s “Reloaded” presentation maps typical enterprise team ownership against the CDM rows. The pattern that emerges is fairly consistent across large organizations:

Devices row: IT operations owns the Identify and Protect cells (asset inventory, patch management, configuration hardening). The security team owns Detect and collaborates on Respond. Something like an Endpoint Services team or IT Operations handles recovery. The friction point is usually in Protect: security sets policy, IT has to implement it, and the two don’t always agree on acceptable risk or operational impact.

Applications row: Application owners or development teams own Identify (they know what the app does and what’s in it) and are the primary actors in Protect (they write and maintain the code). Line-of-business teams often own application-layer Detect through application monitoring and error logging, though they don’t usually think of that as security. Security teams own the security-specific detection use cases: application attack detection, RASP alerts, WAF events.

Networks row: Network Services or IT infrastructure owns Identify and Protect. The security team’s Network Monitoring function owns Detect. Respond is shared, and this is where the handoff breaks most often: when a network security alert fires, who decides to block traffic? Who decides to isolate a segment? Who has the authority to make a change that might break a business application?

Data row: The Chief Data Officer or equivalent (in organizations that have one) owns Identify and Protect for data. Data classification, data inventory, data loss prevention policy. The security team provides tooling and monitoring for Detect. Respond and Recover for data often involve Legal and Compliance in addition to security and IT.

Users row: HR owns the foundational Identify function: the authoritative list of who works here, their role, their access rights by job function. Security owns Detect for user-related threats (insider threat monitoring, behavioral analytics). The Respond function for a user-related incident typically requires HR and Legal involvement in addition to security. Physical Security may own parts of the Users row in some environments.

Where the handoffs break

Knowing who owns a cell is table stakes. Knowing exactly where ownership transfers between cells, and what the handoff mechanism is, is what matters operationally.

Three handoffs break most often:

Identify to Protect across the Devices row. The vulnerability scanner (Devices/Identify) produces a report. Who acts on it? In most organizations, the security team runs the scanner and the IT operations team owns the systems that need patching. The handoff between “we found 340 vulnerabilities” and “340 systems are patched” crosses an organizational boundary, often with no SLA, no escalation path, and no accountability mechanism. The result is vulnerability reports that produce no remediation action, which is arguably worse than not scanning: you know the risk and you’re not mitigating it.

Detect to Respond across the Networks row. A detection event fires. The analyst confirms it’s real. Who has the authority to take containment action? In organizations where network changes require a change management ticket with 48-hour approval, the attacker has moved on before containment happens. Pre-authorizing specific response actions (isolate this segment if this condition is met) requires agreement between the security team and network operations, documented before an incident, not negotiated during one.

Protect to Detect in the Applications row. Application teams own Protect (they wrote the code, they manage the WAF, they handle authentication). The security team owns application-layer Detect. These two functions often don’t talk to each other. When the WAF fires an alert, does that alert go to the security team’s SIEM, or does it go to the application team’s monitoring dashboard? If both, are they correlated? If only the application team, does the security team ever see it?

Building RACI at the cell level

The CDM makes RACI construction practical in a way that generic security RACI templates don’t. Instead of asking “who is responsible for network security” (too broad to be useful), you ask at the cell level.

For each cell, four questions:

Responsible: Who does the actual work in this cell? Who runs the vulnerability scanner, who writes the detection rules, who executes the incident response playbook?

Accountable: Who owns the outcome? If this cell is failing, who is on the hook? This is usually a single person or role, not a team.

Consulted: Whose input is required before decisions are made in this cell? Legal for Data/Respond. Compliance for regulatory-adjacent cells. Business owners for anything that might affect service availability.

Informed: Who needs to know what’s happening in this cell without being involved in decisions? Executive leadership for significant incidents. Audit for compliance-relevant activities.

Yu’s presentations include specific RACI guidance for the Identify and Protect functions. For Identify across the Devices row: establishing inventory is Responsible/Accountable to the asset owner, Informed to Security. Prioritizing inventory is Responsible to the owner, Informed to Security. Measuring vulnerability and attack surface is Responsible to Security, with the asset owner as Accountable/Consulted/Informed. The security team measures the risk; the business owns the asset and the remediation decision.

This allocation matters. Organizations that reverse it, where Security is both measuring risk and accountable for remediation, end up with security teams that are responsible for things they don’t control (patching decisions on systems they don’t own) and business teams that have no skin in the vulnerability management game.

For Protect: configuration and patching are Responsible/Accountable to the asset owner, with Security as Consulted/Informed. Policy definition is Responsible/Accountable to Security, with the asset owner as Consulted/Informed. Security sets the policy; the business implements it. When implementation doesn’t happen, the business owner is accountable, not security.

The manual Identify problem

One of Yu’s specific observations in the “Reloaded” presentation: Identify functions that are performed manually produce poor data quality.

This is worth unpacking. Devices/Identify done manually means someone walking around scanning QR codes on equipment, maintaining spreadsheets, or relying on self-reported asset lists from business units. The data is inevitably incomplete, stale, and inconsistent. You can’t prioritize vulnerability remediation against an asset list that’s six months out of date.

Applications/Identify done manually means asking development teams to self-report what applications and APIs they’ve built and what dependencies those applications have. Software composition analysis done by hand doesn’t scale. The number of open-source components in a typical enterprise application means manual tracking is essentially impossible.

The CDM makes this visible because it forces you to specify not just whether you have a capability in a cell but how that capability operates. “We have asset inventory” as a cell entry is fine. “We have asset inventory maintained by quarterly manual audit” is a different answer, one that should prompt a conversation about whether the data quality is good enough to support the decisions that depend on it.

The manual-vs-automated distinction in Identify cells directly affects every other column. Protect decisions are only as good as your Identify data. Detection rules tied to asset context are only useful if asset context is accurate. The Identify column is the data foundation for the rest of the matrix, and it’s the column where organizations most commonly substitute process theater for actual capability.

Organizational handoffs in an APJ context

In large Japanese enterprises specifically, the organizational structure adds a layer to the handoff problem. Cross-functional authority is rare. Security teams in many Japanese financial institutions and enterprises operate with significant scope limitations: they can advise, they can escalate, they can report to a committee, but they often can’t compel action by IT infrastructure teams or business units.

This isn’t unique to Japan, but the degree of formality around organizational boundaries tends to be higher. A RACI that would be informal and fluid in a US tech company needs to be explicitly documented, formally approved, and embedded in governance processes to work in a Japanese enterprise context.

The CDM is useful here because it produces artifacts: a cell ownership map, a handoff diagram, a RACI table by function. These are the kinds of documents that can go through a steering committee, get stamped, and become the basis for escalation when handoffs fail. Informal agreements about who owns what tend not to survive personnel changes or incident pressure. Documented cell-level RACI, approved at the right level, has more durability.

The other Japan-specific consideration: the Identify column across all rows is often weaker than organizations believe, partly because the responsibility sits with business units that don’t prioritize it and partly because the security team lacks the authority to mandate it. FISC guidelines (Financial Industry Information Systems, the de facto standard for Japanese FSI security) include asset management requirements, but the specific enforcement mechanisms vary. Mapping FISC requirements to CDM cells is a useful exercise for regulated Japanese financial institutions and we’ll cover that in Article 11.

Making handoffs explicit before an incident

The worst time to define a handoff is during an incident. At that point, people are tired, the scope is unclear, leadership is asking questions faster than anyone can answer them, and the organizational politics that prevent clear ownership become acute.

The CDM supports pre-incident handoff definition through tabletop exercises structured around the matrix. Instead of running a generic “ransomware scenario” tabletop, structure it by row: work through a Devices/Detect to Devices/Respond handoff scenario, then a Networks/Detect to Networks/Respond handoff, then a Data/Respond to Data/Recover handoff. Each scenario surfaces the specific handoff gaps in your organization.

The outputs of those tabletops: documented handoff criteria (what condition triggers the handoff?), documented handoff mechanism (Slack channel? Phone call? Ticket system?), documented decision authority (who can approve network isolation at 2am?), and documented escalation path when the responsible party is unavailable.

None of this requires a sophisticated security program to start. It requires time, the right people in a room, and a framework concrete enough to have a specific conversation. The CDM provides the framework.

Next: Article 6 — From Checklist Fatigue to a Real Security Scorecard