CISO’s Corner - 6 Observations from Gartner SRM 2026

Artificial Intelligence continued to dominate the conversation, and content, but the key theme throughout the Gartner Security & Risk Management experience was a little bit more subtle. This year, CISOs from all across the globe came to connect, learn, and explore with peers, vendors, and Gartner, navigating individual and business resilience challenges. What was clear is the fact that the CISO role is evolving, and expanding…regardless of industry, or title, explainability is now the security leaders’ superpower in his or her business.

Here are six observations to discuss with your team, and business leaders in 2026:

1. Criminals and threat actors are taking advantage of your trust

Security leaders are evolving into Trust leaders for the business and there some strong reasons as to why. The most grounded threat content at the summit was not a vendor's AI demo. It was incident-response data, and the pattern was consistent: the trusted layer is now the attack surface, but it’s worth separating two things that frequently get blurred:

• Abuse of trusted channels you operate. Identity, SaaS APIs, native cloud tooling, and increasingly your AI tools already approved for internal use. LevelBlue's DFIR lead, Devon Ackerman, a former FBI Supervisory Special Agent, walked through three cases from a body of 1,500-plus incidents over twelve months that make this concrete:

  • Microsoft Graph API abuse. A phishing lure led to token retention and a malicious OAuth app. The actor used a legitimate JavaScript runtime to enumerate the tenant and pull roughly 8.7 million files from 72 SharePoint subsites in about three days. No malware in the traditional sense. The tooling looked like normal API automation against legitimate cloud interfaces. The visibility gap was SaaS and API telemetry.

  • SEO poisoning into an accidental insider. An employee searching for a regulatory template clicked a poisoned sponsored result, ran a staged downloader, and a single compromised account with mapped drives and Outlook access became a full data-extortion event. No lateral movement, major impact. The visibility gap was browser plus identity context.

  • AI as the threat actor's assistant. This is the AI story that should actually worry you. The actor did not deploy autonomous malware. They used the victim's own Copilot to keyword-search for spreadsheets containing usernames and passwords, surfacing already-accessible data faster than any human could. Treat internal AI as the next generation of shadow IT. It does not break your security, it accelerates discovery of the access you never cleaned up.

• Compromise of trusted things you import. This is the software supply chain, and it is the genuinely separate problem people lump under the same “supply chain risk” banner. The live example during the conference week was a fresh attack on dozens of npm packages tied to a major Linux vendor. "Trusted pipeline attacks" mean a dependency, build step, or upstream maintainer you never vetted ships you the breach. Gartner elevated software supply chain to a critical threat in this year's threatscape, and its own signal is blunt: most applications with third-party flaws carry open-source vulnerabilities. The Graph API case is trust abuse of a channel you run. A poisoned package is trust abuse of a thing you consume. Your controls for each are different, and conflating them is how programs end up over-investing in one while blind to the other.

The connective tissue: in every case the trust was real, and the telemetry was not.

2. Governance & Visibility, and the non-human identity problem nobody budgeted for

If trust abuse is the disease, governance and visibility is the prescription. SaaS and AI sprawl is already difficult to effectively manage and the topic of introducing non-human identity only further complicates success. The Graph API case did not hinge on a stolen password. It hinged on a retained token and a rogue OAuth application acting with delegated permissions. Service accounts, API keys, OAuth grants, and machine identities now outnumber your humans, frequently by an order of magnitude, and most organizations cannot answer basic questions about them: which apps hold which scopes, which tokens never expire, which service account has standing access to the SharePoint site everyone forgot about.

The practical move is to extend identity governance to things that are not people. Inventory OAuth apps and their consented scopes. Audit "Everyone" access and inherited permissions on collaboration platforms. Treat SharePoint like the sensitive database an attacker already considers it to be, not like a document drawer. None of this requires a new AI platform. It requires telemetry from identity, cloud, and SaaS correlated in one place, and someone whose job is to look.

3. Security leaders must do more in navigating financial waste and debt

Two budget signals collided at the summit, and together they point somewhere useful.

The first was the AI spend warning. Security money is leaking into generative AI subscriptions that started near free, moved to per-seat, and now bill per token, often without commensurate results. The honest question Gartner analysts put to the room was whether you are draining budget on things humans still do better. For many SOC tasks, the answer is yes.

The second was the SIEM cost reckoning. The SIEM market is still growing, roughly 17% to 6.8 billion dollars, but the number one buyer concern is cost control, and the analyst guidance was blunt: stop comparing feature lists, measure the outcomes you actually need, and recognize that one valid path is to buy services rather than buy and operate a SIEM.

Organizations are paying premium ingestion costs to pump every log into a SIEM, then paying again for AI to make sense of the volume they over-collected. The cost lever is not a cheaper SIEM. It is collecting and retaining deliberately, pushing detection closer to where the data already lives, and pooling fragmented spend across GRC and SecOps under fewer commercial relationships. A flexible retainer model, where incident response, threat hunting, and advisory hours draw from one pre-committed pool that rolls over, is one way to convert unpredictable breach-driven spend into a fixed line item the board can actually plan around. The point is consolidation of spend, not adding another platform on top.

4. Defining the optimal SOC technology operating model

Despite a long-running vendor consolidation trend, most enterprises run hybrid tooling. SentinelOne here, CrowdStrike there, Palo and Microsoft somewhere in the mix after an acquisition or a regional decision. The SIEM Magic Quadrant session's framing was the right starting point: best of breed, or best for you? Comparing tools on features is comparing apples, oranges, and potatoes. Compare them on the detection and response outcomes you need.

The more important point Eric Ahlm, the analyst covering the SIEM Magic Quadrant made first: a SIEM is not the only lane, and no option is a "must migrate" for every organization. Each new option optimizes specific use cases with real trade-offs, and there are three viable classes to weigh before you assume the answer is a bigger SIEM:

• SIEM wins on open integration and feature depth. The cost is operational weight and the ingestion economics described above.

• Integrated SOC platform wins on simplicity and vendor-provided cross-product collaboration, and it can come with native services attached. The cost is leaning on a single vendor's ecosystem and accepting less open integration.

• Security data lake wins on large-scale data utilization for security outcomes and on cost-controlled storage. The cost is that you build and operate more of it yourself.

Which lane fits is a function of your organization, not the vendor's quadrant position. Build a TDIR needs profile first: team size, security maturity, anticipated data growth, your culture around technology selection, and how much you want to rely on vendor support versus your own people. Match the lane to that profile, then shop for outcomes, not features.

5. The network and cloud edge: where SASE fits, and where Gartner says it stops

While takeaway #4 covered the detection stack, this is about the enforcement edge, and our own data shows why it matters. In the Q1 TTP Briefing, exploited vulnerabilities accounted for 20% of initial access and external remote services (RDP, VPN) for another 11%. The recurring CVEs were overwhelming edge technologies. What this shows? Phishing remains the front door, but the network and cloud edge is now an active frontline, not a solved problem you can quietly outsource and forget.

The instinct here is to consolidate everything onto SASE. Two sessions challenged that instinct, and the nuance is the takeaway.

SASE secures human access well, but was not built for what is coming. It answers "who and what" for users, devices, and branches reaching SaaS and private applications, but Gartner's 2026 view is that SASE is being stretched beyond its design in two areas:

1. Non-human identity: service accounts, API keys, and OAuth grants now outnumber human users and SASE was never designed to govern them.
   
   
2. Agentic AI: Gartner’s own prediction is that by 2028, roughly one-third of GenAI interactions will invoke autonomous agents, many of which will operate outside SASE visibility and control.

The takeaway is not that SASE is insufficient, but that it is simply one layer. Use it to enforce workforce access and govern AI usage, but don’t expect it to secure the agentic layer, software supply chain risks, or machine identity sprawl on its own.

The broader shift is toward a fabric, not a platform. Hybrid Mesh Firewall (HMF) captures this direction: a mix of enforcement points (on-prem, virtual, cloud) managed centrally and integrated with identity, segmentation, and detection controls. In practice, most organizations achieve this through integrations across multiple tools rather than a single purchase.

The common failure mode mirrors the SIEM conversation: chasing a single platform instead of building cohesive coverage across a mixed estate.

The real differentiator is not whether you “have SASE” or “have HMF.” It is whether you can correlate, enforce, and respond across them. That is an operational capability (not a SKU on a vendor’s data sheet). This is precisely why managed network and cloud security and incident response belong in the same conversation rather than separate procurements.

6. Resilience, the actual strategy underneath the buzzword

"Resilience" is a worn word, so here is the operational version. One analyst pressed the room on whether they had defined their minimum viable operations, the core systems they cannot function without. Few hands went up. That gap is the whole game, because the trusted things will fail, whether through a poisoned dependency, a disrupted critical vendor, or a compromised OAuth grant.

Resilience starts by accepting that prevention will not catch all of it. The discipline is threefold:

1. Define what must survive. Identify the handful of systems, processes, and dependencies that directly tie to revenue, safety or regulatory obligations. This includes third parties and SaaS platforms, not just internal assets.
   
   
2. Design your “Plan B” before you need it. If a critical vendor fails, what is the fallback? If identity is compromised, how do you operate in a degraded mode? If a core system is unavailable, what is the manual or alternate path? Most organizations stop at backup. Resilient organizations design continuity of operation.
   
   
3. Test it like an incident, not a checklist. The third-party data here is stark: fewer than 9% of organizations have business continuity plans scoped to their critical third parties, and fewer than 10% include third parties in their continuity testing at all. Yet organizations that conduct third-party incident response planning and maintain a formal contingency plan report roughly 42% to 43% improvements in effectiveness.

The difference is documentation and rehearsal under pressure, with the important shift being that resilience is not owned by security, IT, or risk in isolation. It is a business capability and should be treated as such. The organizations making progress are the ones that treat third-party failure as a first-class scenario, integrate incident response with business continuity, and align technical recovery to business priorities (not system uptime). In practice, resilience is not about restoring everything but restoring the right things first and knowing exactly what those are.