How to Build a Unified Cybersecurity + Information Security Program Without Creating Two Competing Teams

Dave Mathew — Thu, 24 Sep 2026 11:18:56 +0000

Walk into most mid-sized organizations and ask, "Who owns security?" and you'll often get two different answers from two different people sitting in two different meetings. One team lives in the SOC, chasing alerts, patching vulnerabilities, and responding to incidents. The other lives in governance, risk, and compliance; writing policy, managing audits, and mapping controls to frameworks. Both are doing real, necessary work. Both often believe the other team is slowing them down.
This is the quiet dysfunction at the heart of a lot of security organizations: cybersecurity and information security have grown into separate disciplines with separate reporting lines, separate tools, and separate definitions of "done." When leadership finally decides to build a unified cybersecurity and information security program, the challenge isn't technical; it's organizational. Done poorly, unification just creates a bigger team with the same internal friction. Done well, it turns two competing functions into one coherent risk operation.

This piece is a practical guide for CISOs and security leaders designing that structure: where the friction actually comes from, what a workable operating model looks like, who should own what, and how to sequence the change without breaking what already works.

Where the Friction Actually Comes From

The tension between cyber and infosec rarely starts as a personality conflict. It starts as a structural one, and it shows up in a few predictable ways.

Different time horizons. Cybersecurity operates in minutes and hours; an alert fires, a host gets isolated, a patch goes out. Information security operates in quarters and years: policy reviews, audit cycles, risk assessments. When these two clocks run in the same building without coordination, cyber sees infosec as bureaucratic and slow, and infosec sees cyber as reactive and undocumented.
Different definitions of risk. The cyber team often thinks in terms of exploitability and blast radius. The infosec team thinks in terms of control maturity and compliance gaps. Both are legitimate risk lenses, but without a shared register, they produce two separate risk pictures that rarely get reconciled, which means the board sometimes gets two different stories depending on who's presenting.
Duplicate ownership of the same assets. Vendor risk is a good example. Cyber wants to know if a vendor's environment could be a path into yours. Infosec wants to know if the vendor meets contractual and regulatory security requirements. Too often, both teams run separate vendor assessments, ask the vendor different sets of questions, and never compare notes, burning goodwill with vendors and creating gaps neither team can see alone.
Competing narratives to leadership. When cyber and infosec report through different chains, they tend to bring different priorities to budget and planning conversations. Leadership ends up mediating a rivalry instead of making a resourcing decision, and the org effectively adjudicates security strategy by committee politics rather than risk data.

None of this is inevitable. It's the predictable outcome of building two teams around two different mandates and never designing the connective tissue between them.

A Workable Operating Model: Shared Risk, Joint Exercises, Clear Ownership

Unifying cyber and infosec doesn't necessarily mean collapsing them into a single team with identical job descriptions; technical depth and governance depth are genuinely different skill sets. What needs to be unified is the operating model: the shared artifacts, cadences, and decision rights that make both functions pull in the same direction.

1. One risk register, not two

This is the single highest-leverage change most organizations can make. Instead of a "cyber risk log" and a "compliance risk register" living in different tools, maintain one risk register with fields for both technical exploitability and control/compliance status. Every risk entry gets a single owner, a single severity rating methodology, and a single review cadence. When cyber identifies a technical exposure, it should land in the same register infosec uses to brief auditors and the board. This alone eliminates most of the "two stories" problem.

2. Joint tabletop and incident exercises

Run incident response tabletops with both teams in the room; not cyber running the technical scenario and infosec reviewing the after-action report a week later. When infosec understands the operational reality of a live incident, policies get written that people can actually follow under pressure. When cyber understands what evidence and notifications a real breach will require, response playbooks stop missing the compliance steps that turn a bad day into a regulatory problem.

3. Clear ownership, not shared ownership

The instinct to make everything "co-owned" is well-intentioned and usually backfires. Shared accountability without a single decision-maker just recreates the original friction with extra steps. Instead, every recurring activity should have exactly one accountable owner, with the other functioning as a required consulting or informed party. That's the point of the matrix below.

4. A joint operating rhythm

A monthly (not quarterly) joint review where both leads walk through the shared risk register, open incidents, upcoming audits, and vendor findings together keeps the two disciplines synchronized without requiring a full reporting-line merger. This is often the fastest, lowest-cost step an organization can take before any restructuring happens at all.

A Simple Ownership Matrix

Ambiguity is the enemy here. Below is a starting RACI for the activities that most often cause cross-team conflict. Adjust the names, not the principle: every row needs exactly one "A."

Incident Response — Technical

Cybersecurity (Ops/SOC): Responsible and Accountable (R/A)
Information Security (GRC): Consulted (C)
Legal/Privacy: Informed (I)
Business Unit: Informed (I)

Incident Response — Regulatory/Notification

Cybersecurity (Ops/SOC): Consulted (C)
Information Security (GRC): Responsible and Accountable (R/A)
Legal/Privacy: Consulted (C)
Business Unit: Informed (I)

Vendor Risk Assessment — Technical

Cybersecurity (Ops/SOC): Responsible and Accountable (R/A)
Information Security (GRC): Consulted (C)
Legal/Privacy: Informed (I)
Business Unit: Consulted (C)

Vendor Risk Assessment — Contractual

Cybersecurity (Ops/SOC): Consulted (C)
Information Security (GRC): Responsible and Accountable (R/A)
Legal/Privacy: Consulted (C)
Business Unit: Consulted (C)

AI Governance — Model/Tooling Risk

Cybersecurity (Ops/SOC): Responsible and Accountable (R/A)
Information Security (GRC): Consulted (C)
Legal/Privacy: Consulted (C)
Business Unit: Informed (I)

AI Governance — Policy & Acceptable Use

Cybersecurity (Ops/SOC): Consulted (C)
Information Security (GRC): Responsible and Accountable (R/A)
Legal/Privacy: Consulted (C)
Business Unit: Consulted (C)

Audit Evidence Collection

Cybersecurity (Ops/SOC): Responsible (R)
Information Security (GRC): Responsible and Accountable (R/A)
Legal/Privacy: Informed (I)
Business Unit: Consulted (C)

Physical Security

Cybersecurity (Ops/SOC): Informed (I)
Information Security (GRC): Consulted (C)
Legal/Privacy: Informed (I)
Business Unit: Responsible and Accountable (R/A)

*Physical security ownership often sits with Facilities or Corporate Security rather than either information security function directly. However, Information Security should retain oversight of how physical controls map to compliance frameworks, such as ISO 27001 Annex A physical controls.

Key Points

Two things are particularly important about this ownership structure.

First, several activities appear twice because they should be separated into a technical component and a governance component. This split is often the real source of cross-team conflict.
For example, vendor risk assessment and incident response contain both technical and governance responsibilities. Trying to assign a single owner to the entire activity can result in duplicated work, unclear responsibilities, or important tasks being overlooked.
Second, AI governance should have its own dedicated ownership category rather than being treated as something to address later. AI governance increasingly requires** coordination between cybersecurity and information security because it involves both technical and governance risks.
Technical risks can include model access, data exposure, security vulnerabilities, and AI tooling. Governance risks can include acceptable-use policies, third-party AI tools, regulatory exposure, and organizational oversight**.
Separating these responsibilities clearly helps ensure that **cybersecurity, information security, legal/privacy, and business teams **understand where their responsibilities begin and end.

Layering NIST CSF and ISO 27001, Not Choosing Between Them

One of the more avoidable sources of friction is treating frameworks as team identities; cyber "does NIST,"infosec "does ISO." This is a false choice, and it actively reinforces the org split you're trying to fix.
NIST CSF is best understood as an operational risk-management lens: Identify, Protect, Detect, Respond, Recover. It's built for how a security operations function actually thinks about day-to-day risk and maturity. ISO 27001 is best understood as a management-system standard: it defines how a security program is governed, documented, audited, and continuously improved (via an ISMS), with Annex A giving you a control catalog.
These aren't competing philosophies; they answer different questions.
NIST CSF answers "how mature and effective is our security capability?" ISO 27001 answers "is our security program properly governed, documented, and independently verifiable?" A unified program uses NIST CSF functions to structure how cyber operations measure and report its own maturity, and uses the ISO 27001 ISMS as the governance wrapper that infosec maintains around the entire program, including the parts cyber operates day to day.
In practice, that means building a single control-mapping spreadsheet where every NIST CSF subcategory **is cross-walked to its corresponding ISO 27001 Annex A control (and to any other framework you're obligated to; SOC 2, HIPAA, PCI DSS)**. One control, multiple framework citations, one piece of audit evidence. Teams stop debating which framework "wins" and start treating both as different views into the same underlying control set.

Implementation Advice for Mid-Sized Organizations

Most guidance on unifying security functions is written for enterprises with the headcount to build parallel teams and slowly merge them. Mid-sized organizations don't have that luxury; usually a handful of people are wearing both hats already. That's actually an advantage if you sequence the change correctly.

Start with the artifacts, not the org chart. Before you touch reporting lines, build the shared risk register and the framework cross-walk. These are low-political-cost changes that immediately reduce duplicate work, and they create the shared language a structural change will later depend on.
Appoint a single accountable leader before you appoint a single team. Even if cyber and infosec keep separate reporting lines for now, name one person — often the CISO; as accountable for the unified risk register and the joint operating rhythm. Structure can follow later; accountability shouldn't wait for it.
Don't force every role to become a generalist. The temptation in a small team is to make everyone do everything. Resist it. Keep technical depth and governance depth as distinct skill sets, but make sure every person understands enough of the other side to translate; a SOC analyst who can write a clean incident summary for an auditor, a GRC analyst who understands what "lateral movement" actually means.
Use the joint tabletop as your forcing function. If you do nothing else this quarter, run one incident response exercise with both functions in the same room, working from the same risk register. It will surface more structural gaps in ninety minutes than a reorg planning document will in three months.
Revisit the ownership matrix quarterly. As the AI governance row above shows, new categories of risk will keep appearing faster than your org chart updates. Treat the RACI as a living document, not a one-time deliverable.

A unified cybersecurity and information security program isn't really about merging two departments on paper. It's about making sure both functions are working from the same risk picture, the same framework mapping, and the same accountability structure, so that when something goes wrong, the organization has one coordinated response instead of two competing narratives.

DEV Community: Dave Mathew