CISO vs. SOC Manager: Who Owns What in Security Governance and Operations?

A lot of security teams don’t fail because of bad tools. They fail because nobody can answer one simple question: who owns what between the CISO and the SOC Manager?

In most orgs, the CISO owns the “why and what” (risk decisions, policies, and funding), while the SOC Manager owns the “how” during operations (alerts, triage, response workflows, and reporting). The line sounds clear on paper, but in real life it gets messy fast—especially during an incident, a budget fight, or a compliance deadline.

Below is a plain-English breakdown of CISO vs. SOC Manager responsibilities for security governance and security operations. I’ll also share a RACI-style ownership model you can copy for 2026, plus common mistakes I’ve seen in the wild.

Quick answer: CISO owns governance; SOC Manager owns operations

The CISO is accountable for security governance. That means risk choices, security strategy, policies, standards, and how the business measures success.

The SOC Manager is accountable for security operations. That means alert intake, triage, investigation handoffs, incident workflow execution, and day-to-day performance of the SOC team.

Both roles matter. But if you mix their ownership, you get long approval loops, slow incident response, and confusion during audits.

What a CISO actually owns (security governance in plain words)

The CISO owns the rules of the security game—and the outcomes the company is willing to accept.

Security governance is the set of decisions and controls that shape what your org does, why it does it, and how it proves it’s working. In 2026, most CISO mandates connect to things like cyber risk reporting, board-level metrics, regulatory needs, and internal policy.

CISO governance responsibilities you can list for audits

If you need this role split to hold up in an audit, keep it specific. Here are the governance areas I expect a CISO to own:

• Security strategy and risk appetite: deciding how much risk the company can tolerate (example: “we accept residual risk for non-prod systems, but not for customer login flows”).
• Policies and standards: security policies (high level) and security standards (how things must be done). For example, an access control standard that says MFA is required for privileged access.
• Security awareness and behavior rules: training programs and expected user actions during phishing attempts and account takeover events.
• Third-party and vendor security requirements: what your vendors must meet (SOC 2 evidence, pen test cadence, incident notification timelines).
• Compliance ownership: mapping controls to frameworks (like ISO 27001, NIST CSF, CIS Controls) and ensuring evidence exists.
• Budget and resourcing decisions: funding for tools, people, and processes. This is often where governance meets reality.
• Escalation and executive reporting: telling leadership what’s happening in a way they can act on.

One opinion from experience: I trust a CISO who talks in measurable terms, not vague ones. “We improved detection” isn’t enough. You want numbers like time-to-triage (TtT), time-to-contain (TtC), alert quality (low/medium/high), and coverage for the systems that matter.

CISO vs. SOC Manager ownership: governance vs. execution

Here’s the simple mental model I use:

• CISO: sets the “what” (policy) and “why” (risk).
• SOC Manager: runs the “how” (triage, investigation workflow, response execution).

For example, the CISO writes or approves a policy that says “privileged access requires MFA.” The SOC Manager then makes sure alerts for “privileged login without MFA” are monitored, triaged, and escalated using the right playbooks.

What a SOC Manager actually owns (security operations in 2026)

The SOC Manager owns what happens after an alert fires—every day, every shift, every week.

Security operations is the part that people feel. It includes detection monitoring, alert triage, investigations, incident coordination, case management, and continuous improvement of the SOC workflow.

In 2026, most SOCs are hybrid or layered (internal analysts plus threat hunting plus automation). The SOC Manager is still the person who makes sure the machine works and the humans know what to do.

SOC Manager responsibilities that keep incidents from turning into disasters

When I look at SOC maturity, the SOC Manager owns these core operational areas:

1. Alert intake and triage: deciding what gets investigated first, who gets paged, and how to reduce noise.
2. Investigation workflows: documenting steps and using repeatable playbooks (example: “possible ransomware spread” runbook).
3. Case management: tracking investigation notes, evidence, decisions, and final outcomes.
4. Escalation paths: knowing when to pull in IT Ops, Identity team, application owners, or incident response leadership.
5. Incident coordination support: working the timeline, collecting logs, and updating stakeholders.
6. Tool operations and tuning: managing SIEM rules, SOAR workflows, EDR alert routing, and log source health.
7. Quality and KPIs: reporting metrics like coverage, detection quality, mean time to triage, and analyst workload.
8. Training and shift handoffs: running drills and making sure the SOC can follow the same process at 2 a.m.

Practical example: If your SIEM uses Microsoft Sentinel and Defender for Endpoint, the SOC Manager should manage how alerts are normalized, how incidents are grouped, and how analysts interpret the alert story. That’s the “operations” part, not the governance policy part.

What “SOC Manager” includes besides monitoring

People often think SOC work is just watching dashboards. It’s not. A strong SOC Manager also drives:

• Detection engineering feedback loops: sending findings to engineering when rules create false positives or miss real threats.
• Threat hunting: using hypotheses and targeted queries to check what the alerts don’t catch.
• Automation improvements: building SOAR playbooks (for example, enriching an IP, checking blocklists, and tagging the case) so analysts can focus on real investigations.
• Ransomware and phishing simulations: coordinating with internal teams so response plans are tested, not guessed.

Where the line gets blurry: real scenarios and who steps in

Most confusion happens at the edge of governance and operations. Here are common scenarios and how to decide who owns the move.

Scenario 1: The SOC finds an Identity weakness

Example: Analysts see repeated failed logins on privileged accounts, plus stale group memberships in Azure AD/Entra ID.

• CISO owns: the risk decision (is this acceptable? how severe is it?), policy priorities (what must change first), and whether to fund a new control.
• SOC Manager owns: the operational response (investigate, confirm impact, open cases, escalate to Identity team, and track containment steps).

What most teams get wrong: the SOC Manager is asked to “write the policy” while also doing investigations. That delays both. The SOC Manager documents what happened and what should change. The CISO (with Legal/Compliance and IT leadership) approves the policy changes and resource plan.

Scenario 2: Board asks “Are we compliant?”

In 2026, leadership wants quick truth: evidence exists, controls work, and gaps are tracked.

• CISO owns: compliance mapping, control ownership, and executive reporting.
• SOC Manager owns: operational evidence (alert and incident logs, KPI trends, case counts, and incident timelines) that support control effectiveness.

In other words, the SOC Manager provides proof. The CISO decides how the story is told and what’s missing.

Scenario 3: A zero-day incident hits

When there’s active exploitation, speed wins. Your SOC can’t wait for policy approval mid-incident.

• CISO owns: high-level risk posture (how far you go, what systems you isolate first) and the call to pause risky business operations if needed.
• SOC Manager owns: incident execution under the playbooks (containment actions they are authorized to take, log collection, escalation timing, and ongoing case management).

Tip: Write “decision rights” into incident response plans. If the SOC Manager needs CISO approval to block a domain controller or disable an app, say that clearly and define response time targets.

A practical RACI split for CISO vs. SOC Manager ownership

If you want fewer arguments and faster response, use a RACI model (Responsible, Accountable, Consulted, Informed). It’s not fancy—it’s just a table that stops people from guessing.

Below is a solid starting point you can adapt. I’ve used variations of this in real orgs because it maps well to how security governance and operations actually work.

Original insight: Many teams treat “R” as “responsible for everything.” Don’t. Put “A” (accountable) where the decision must land. If the CISO is accountable for policy, the SOC Manager should not be the final decision-maker on governance changes—even if they’re the one with the most technical context.

Key metrics to align both roles (and stop blame games)

You can’t fix role confusion with org charts alone. You fix it with shared metrics.

In my experience, the best teams split metrics into two buckets: governance outcomes and operations performance. Then they review both in a consistent cadence.

Governance metrics the CISO should own

• Risk reduction progress: % of high-risk findings remediated within a set timeframe (example: 60–90 days for “critical” items).
• Policy and control coverage: % of systems covered by required controls (MFA on privileged access, logging enabled for critical apps).
• Compliance control effectiveness: pass/fail trend on control testing, plus evidence completeness rate.
• Security training completion: phishing click rates and report rates, tracked by department.

Operations metrics the SOC Manager should own

• Time to triage: median and 90th percentile (for example, “P90 triage under 15 minutes”).
• Time to contain: how quickly threats are contained after confirmation.
• Alert quality: false positive rate by rule; number of alerts per true incident (noise level).
• Case backlog: open case counts by age buckets (0–2 days, 3–7, 8–30, 30+).
• Detection coverage: visibility gaps (missing logs from key systems) and how fast they’re fixed.

How to review these metrics without starting fights

Use a monthly joint review with a strict agenda:

1. What changed: new regulations, new systems, new tooling.
2. What broke: incidents, high false positives, gaps in coverage.
3. What decisions are needed: which policies need updates and which SOC workflows need tuning.
4. Owners and dates: set action items with one accountable person per task.

When you do this, CISO vs. SOC Manager confusion becomes a process problem, not a personal problem.

Common mistakes that create “CISO vs. SOC” conflict

Here are the patterns I’ve seen repeatedly. If you recognize yourself, fix it now—before a real incident forces it.

Mistake 1: Treating SOC operations like governance

Some CISOs want to approve every playbook change or SIEM rule update. That slows response and kills momentum.

Better approach: The CISO sets guardrails (risk rules, escalation thresholds, what’s allowed), and the SOC Manager runs the playbooks within those boundaries.

Mistake 2: Treating governance tasks like SOC “homework”

Another common issue is when the SOC Manager is told to fix policy gaps, compliance evidence, and vendor reviews—while still doing on-call and incident work.

Better approach: SOC provides operational facts (what happened, what controls worked, what failed). Governance decisions stay with the CISO and control owners.

Mistake 3: No decision rights during incidents

If your incident runbooks don’t say who can shut down systems, isolate endpoints, or pause deployments, your team will freeze under pressure.

Fix it in 2 hours: add a “Decision Rights” section to your IR plan with time targets and escalation triggers.

Mistake 4: Using only tooling for accountability

“We use Microsoft Sentinel so we’re covered” is not a governance strategy. Tools help. But ownership of decisions and outcomes matters more.

This is why I like pairing SIEM/EDR metrics with governance outcome metrics. It ties operations to risk reduction.

People also ask: CISO vs. SOC Manager

These are the questions I see most often in security job interviews, internal org design, and leadership calls.

Who does incident response belong to, the CISO or the SOC Manager?

Incident response belongs to both, but at different layers. The SOC Manager owns execution under playbooks (triage, investigation, containment steps, case management). The CISO owns escalation decisions and the risk posture for bigger moves (for example, declaring a major incident, coordinating executive comms, or directing business-wide shutdowns when needed).

The key is pre-defined decision rights. If you wait until the incident is happening to negotiate ownership, you lose time.

Can a SOC Manager be accountable for security governance?

A SOC Manager can contribute. They often know what’s working in real time. But accountability for security governance should still sit with the CISO or a governance council.

Reason: governance includes policy approval, risk acceptance, compliance mapping, and budget decisions. Those require authority across business units, not just operational expertise.

What should the CISO not get involved in day to day?

• Day-to-day alert triage decisions.
• Manual approval for every SIEM rule change or SOAR workflow tweak.
• Analyst scheduling and shift-level performance management.

The CISO can review outcomes and approve guardrails, but day-to-day execution belongs with the SOC leadership team.

What tools does each role care about most?

• CISO cares about tool outcomes: “Does it reduce risk? Does it support compliance evidence? Can we measure time to detect/contain?”
• SOC Manager cares about tool operations: rule performance, log sources, alert grouping, case workflows, and playbook automation.

For example, the SOC Manager may own how Microsoft Defender incident signals are normalized in Sentinel. The CISO cares whether that detection coverage supports the risk strategy for identity threats.

How to set up a clean ownership model in 30 days

If you want a fast, realistic plan, do this over four weeks. It takes less time than you think, and it prevents chaos later.

Week 1: Map ownership in a RACI workshop

Bring the CISO (or security director), SOC Manager, IT Ops lead, Identity lead, and compliance owner. Agree on accountable owners for 10–15 key activities.

Output: one table that everyone can reference during incidents and audits.

Week 2: Write decision rights for incidents

Update your incident response plan with:

• What the SOC Manager can do without approval
• What requires CISO approval
• Expected approval timelines (example: within 15 minutes for major containment decisions)
• When you escalate to exec leadership

This is where incidents stop being political and start being operational.

Week 3: Align KPIs and reporting cadence

Pick 6–10 shared metrics. Split them by governance vs. operations. Then set meeting dates with deadlines for action items.

If your SOC metrics show slow triage, the CISO should treat it as a resourcing or process risk—not as a personal blame issue.

Week 4: Test the model with drills

Run at least one tabletop exercise using a real scenario from your environment. For example:

• Compromised admin account in Entra ID
• Suspicious PowerShell + EDR detections
• Ransomware note triggered by a known attack technique

During the drill, watch for delays caused by unclear ownership. Fix the plan while memories are fresh.

Where this doesn’t fit: smaller orgs and shared roles

In small companies, the same person might act as both CISO and SOC Manager. That can work, but only if you still separate governance tasks from operational tasks by time and checklist.

For example, if one person is handling everything, create two daily routines: one governance review block (policy, risk, compliance evidence) and one operations block (alerts, triage, investigation). Otherwise, governance quietly disappears until a regulator or incident forces it back.

Conclusion: Make ownership boring, so security can be fast

Here’s the takeaway I want you to leave with: CISO vs. SOC Manager is not a power struggle. It’s a division of responsibilities—governance decisions belong to the CISO, and operational execution belongs to the SOC Manager.

If you want fewer delays and cleaner accountability, do three things: use a RACI table, define decision rights in your incident plan, and align governance KPIs with SOC performance metrics. When those pieces fit together, security operations gets faster, and governance gets more credible—especially in 2026 when both audits and attackers move quickly.

Related reading on our site:

• How to build a SOC KPI dashboard (alert quality + triage speed)
• Identity threat detection playbooks for Entra ID and hybrid environments
• 2026 SIEM tuning best practices: reduce noise without losing coverage
• Ransomware incident runbook: roles, timelines, and containment steps

Featured image alt text suggestion (for the page editor): CISO vs. SOC Manager security governance and operations ownership chart showing incident workflow roles.