The most damaging breaches do not always require a brilliant exploit. Sometimes the access an attacker needs has already been granted — to a user, a third party, a service account, or an application.
A single breach at one market research provider reached close to two hundred companies – among them several cybersecurity firms. Not through a novel vulnerability, but through a trusted connection that was already in place.
Incidents like these raise a broader question that technology leaders need to ask: when security depends on controls operated across IT, engineering, identity, cloud and third parties, who actually owns the outcome?
The org chart illusion
Ask who owns security in your organization and the answer arrives quickly: the security team.
Now ask a narrower set of questions. Who owns patching across the server estate? Who owns the identity lifecycle for contractors and third parties? Who sets and enforces cloud configuration standards? Who approves a new SaaS tool before it touches company data? Who decides what an AI agent is permitted to access?
Those answers come more slowly and are often less clear. In most organizations they sit distributed across IT, engineering, platform teams, procurement and security – and the seams between those groups are precisely where risk can accumulate.
This is not dysfunction. It is the natural result of how the work grew. Security teams were built to set standards and manage risk. IT teams were built to run the estate. That division worked reasonably well when the estate had a perimeter and a countable number of things inside it.
That is no longer the environment any of us operate in.
The surface grew faster than the org chart
Consider how much has changed in a short period. Non-human identities – service accounts, workloads, bots and now autonomous agents – can significantly outnumber human identities in enterprise environments. Eighty-eight percent of organizations have reported a confirmed or suspected AI agent security incident, yet only twenty-two percent govern those agents as distinct identities with their own credentials and access boundaries. Third-party and supply chain access remains a significant and growing route into an organization.
Many of these risks cross traditional organizational boundaries.
Consider an AI agent. It may be provisioned by engineering, authenticated through an identity platform administered by IT, given access to data governed by another function, and deployed into a business process owned by yet another team.
Ask who is accountable for what that agent can reach, what it can do with the information it retrieves, and whether that access remains appropriate six months later. The answer is not always obvious.
That is the gap. Not a missing control – sometimes it is simply missing or fragmented accountability.
What shared responsibility actually means?
“Everyone is responsible for security” is a poster, not an operating model. In practice it tends to mean no one is.
Shared responsibility does not mean shared ambiguity. In fact, it should mean exactly the opposite.
Security may define the control objective, establish the risk threshold and provide oversight, while IT, engineering or another technology function owns implementation and operational performance. Security does not need to patch every server to establish patching requirements. It does not need to provision every identity to define appropriate access standards. And it does not need to build every AI agent to establish the security boundaries within which those agents should operate.
Accountability and execution are different things — and mature security operating models make both explicit.
Shared responsibility means that for every meaningful risk in the environment, someone outside the security team owns an outcome, while the security team owns the standard, the visibility and the escalation path. It means IT is measured on security outcomes, not only on uptime and delivery speed. And it means security is measured in part on whether it made the secure path the easy one.
That last point deserves emphasis. Security leaders often describe a tension between being a guardian and being a roadblock. In my experience that tension is usually a symptom rather than a cause. When teams route around security, it is rarely because they do not care about risk. It is because the secure path was slower, less documented, or harder to find than the alternative.
Shared responsibility only works when the shared path is genuinely usable.
What I would look for?
If I were trying to determine whether IT and security were genuinely operating as one technology organization, I would look for five things.
A joint risk review. IT and security work the same risk register together, on a fixed cadence, with a named owner against every item. Not a security readout delivered to IT, but a shared conversation producing shared decisions.
Connected visibility. Organizations do not necessarily need one system containing every asset, identity, data source and third-party relationship. But they do need enough connected visibility to answer some basic questions: What do we have? Who or what can access it? Who owns it? How sensitive is it? And what risk does that access create?
A shared scorecard. If security measures appear only in the security team’s review, the model has already failed. Patch latency, identity hygiene and configuration drift belong on the IT scorecard too, alongside traditional measures such as availability.
Blameless postmortems across both teams. Incidents that touch the seam between IT and security should be reviewed jointly. The goal is a systems answer – what made this failure possible – rather than a team-level answer about who missed something.
Embedded partnership. A named security partner for each major technology group, present early enough to shape decisions rather than review them afterwards. Security is far more effective when it participates in architecture and technology decisions before they become remediation projects.
Questions worth taking to the board
Boards increasingly ask whether an organization is secure. It is a difficult question to answer honestly, and often the wrong one to ask.
I think there are more useful questions:
For our most significant technology risks, who owns the outcome?
Where do IT and security share measurable accountability for reducing those risks?
And when a control spans security, IT, engineering and the business, who is accountable for making sure nothing falls between them?
The answers to those questions describe an operating model. That model, far more than any individual control, determines what happens on a bad day.
Where this goes?
None of this requires a reorganization, and I would be cautious of anyone selling one. What it requires is a shift in how ownership is assigned and measured – and a willingness to treat the space between teams as somebody’s explicit responsibility rather than a gap everyone assumes someone else is watching.
The environment will keep expanding. Agents will proliferate. Third-party dependencies will deepen. Data will become easier for both humans and machines to discover and consume. The boundaries between identity, data, infrastructure, applications and security will continue to blur.
Our operating models have to evolve with them.
The organizations that hold up over the next few years will not be the ones with the largest security teams. They will be the ones where security stopped being one team’s job and became a set of outcomes the whole technology organization is accountable for.
Security doesn’t own security. It never really did.
But security does have an important responsibility: to ensure there is clarity around who owns each security outcome — and that none of those outcomes disappear in the space between teams..
