Cybersecurity challenges for businesses in 2026-2027: tool sprawl, regulation and shadow AI

A firewall from one vendor, an EDR from another, email filtered by a third, a SIEM ingesting data from all of them and a vulnerability scanner that only gets opened before the audit. Each piece arrived for a sound reason, whether an incident, a renewal or a regulatory requirement. Taken together, they add up to dozens of consoles, alerts that are never correlated and a team that spends more hours maintaining tools than detecting attacks.

The cybersecurity challenges of 2026 and 2027 deepen that trend, because each new vulnerability, regulation or use of AI tends to be met with another tool or another provider. International data makes it possible to measure why tool sprawl keeps growing, what it costs, how regulation, hardware and AI feed it, and when an external cybersecurity provider helps to reduce it and when it makes things worse.

What cybersecurity challenges will shape 2026 and 2027 for businesses?

The cybersecurity challenges for 2026 and 2027 are vulnerability exploitation, dependence on third parties, shadow AI, regulatory pressure and the skills shortage. According to the Verizon 2026 Data Breach Investigations Report, which covers more than 22,000 confirmed breaches in 145 countries, vulnerability exploitation is now the most common known initial access vector.

• Vulnerability exploitation was the initial vector in 31% of breaches, up from 20% in the previous report, and only 26% of the critical flaws in CISA's KEV catalogue were fully remediated, with a median of 43 days.
• Third parties were involved in 48% of breaches, a 60% rise on the previous year.
• 45% of employees now use AI regularly at work, and 67% of those accessing AI on corporate devices do so through non-corporate accounts.
• DORA and the national laws transposing NIS2 set deadlines of hours for reporting major or significant incidents. Spain's ENS, and PCI DSS through contracts, also call for continuous monitoring and regular testing.
• Skilled people are scarce. In the ISC2 2025 study, which polled more than 16,000 professionals, 59% reported critical or significant skills shortages, up from 44% a year earlier.

In Spain, INCIBE handled 122,223 incidents in 2025, 26% more than in 2024, and detected 237,028 relevant vulnerable systems.

What is security tool sprawl?

Security tool sprawl is the build-up of protection, detection and compliance products that overlap, do not share data and each demand a console, a licence and a specialist. It grows by addition: every new risk or requirement brings a product, and almost none are retired.

Over the years the organisation pays for duplicated functions, leaves gaps uncovered and depends on people who know tools that nobody else can operate. Spending follows the trend. In July 2025 Gartner forecast worldwide information security spending of around $240 billion in 2026, 12.5% more than in 2025.

How many security tools does a company use?

A large company uses between 45 and 83 security tools on average, depending on the study. In March 2025 Gartner put the average at 45 in a survey of 162 large enterprises and noted that the market has more than 3,000 vendors.

The IBM Institute for Business Value and Palo Alto Networks counted 83 solutions from 29 different vendors after surveying 1,000 executives across 21 industries and 18 countries. 52% named complexity as the biggest obstacle to their cybersecurity operations. Palo Alto Networks sells integrated platforms, a commercial interest to bear in mind when reading the figure.

Cisco's 2025 Cybersecurity Readiness Index, based on 8,000 leaders in 30 markets, adds the operational effect. Over 77% say their infrastructure, with more than ten point solutions, stops them responding quickly. Only 4% reach the index's top maturity level.

Why is it so hard to integrate security tools?

Integrating security tools is hard because each product does its own job well and the failures appear at the joins between them.

• Each product has its own console, alert model and query language, so an analyst investigating an incident jumps between five or six screens to piece it together.
• A firewall, an EDR and a cloud service describe the same user, IP address or process with different fields and names; without normalisation, the SIEM stores data it cannot correlate. Each SIEM also uses its own data model (CIM in Splunk, ASIM in Sentinel, UDM in Google Security Operations, ECS in Elastic), so changing SIEM means redoing parsers and rules.
• Connectors and APIs change with every release, and an integration can stop sending events without anyone noticing until they are missing from an investigation.
• Every contract renews on a different date and is measured differently (per user, per device, per gigabyte ingested), which makes it harder to retire products and calculate total cost.
• When the person who configured a tool leaves, it keeps running, but nobody can explain why it raises the alerts it raises.

The SANS 2025 SOC Survey, with participants from 57 countries, shows the outcome. 42% of SOCs send all incoming data to the SIEM with no plan for managing or retrieving it. Its author warns leadership that if the resources needed to make a tool effective will not be committed, it is better not to deploy it at all.

Does the skills shortage make it worse?

The skills shortage makes it worse, because every additional tool needs someone who understands it. According to ISC2, 88% of the professionals surveyed report at least one significant cybersecurity event caused by skills shortages. ISC2 has also stopped estimating the global workforce gap and moved to measuring skills shortfalls.

Cisco points the same way: 86% of organisations see the shortage of specialists as a major challenge, and more than half have over ten cybersecurity roles unfilled. In the SANS survey, 62% of SOC professionals believe their organisation is not doing enough to retain talent, one reason many companies turn to a managed SOC.

How does regulation push companies to add tools?

Regulation pushes companies to add tools because it requires continuous monitoring, incident reporting within hours, regular testing of defences and evidence for all of it. NIS2, DORA, the ENS, PCI DSS and ISO 27001 phrase it differently, and each obligation tends to be met with a new product, service or report.

None of these frameworks requires a specific product. The risk arises when each requirement is covered separately: one SIEM for the ENS, another provider for the PCI DSS penetration test, a compliance platform for ISO 27001 and the DORA register of information kept in a spreadsheet. An organisation subject to several frameworks ends up maintaining duplicate evidence, and the same control is audited several times with different tools.

Senior management cannot hand the matter off either. Article 20 of NIS2 requires Member States to make the management bodies of essential and important entities approve cybersecurity measures, oversee their implementation, answer for non-compliance and undergo training. In finance, Article 5(2) of DORA already gives the management body that responsibility. The comparison of ENS, ISO 27001, NIS2 and DORA helps to identify shared controls that can be covered once.

Has Spain transposed NIS2?

Spain had not transposed NIS2 as of 4 November 2026. The Council of Ministers approved the draft Cybersecurity Coordination and Governance Act on 14 January 2025, and the act has not been published in the Official State Gazette (BOE). Meanwhile Royal Decree-law 12/2018, which transposed the first NIS Directive, still requires operators of essential services and digital service providers to report incidents. On 8 July 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the EU Court of Justice for failing to transpose the directive and asked for financial penalties for all four.

Waiting for the law does not lighten the load. Financial entities have applied DORA since 17 January 2025. The public sector and companies supplying services for the systems involved apply the ENS, and anyone storing, processing or transmitting cardholder data must comply with PCI DSS under contracts with the card brands and its acquiring bank. Preparing for NIS2 on that foundation avoids building yet another layer of tools when the law arrives.

Why is shadow AI a governance challenge?

Shadow AI is a governance challenge because unapproved tools and agents spread faster than their controls, and every point solution adds another layer of sprawl. It covers AI tools and agents that the company has not approved or does not control. It also spans no-code automations (Power Automate, Zapier or n8n), personal API tokens and MCP servers connected to email, the CRM or code repositories with broad permissions and no owner.

The data shows control lagging behind use. In the Microsoft and LinkedIn 2024 Work Trend Index, covering 31,000 people in 31 countries, 75% of knowledge workers already used AI, and 78% of them brought their own AI tools to work. IBM's Cost of a Data Breach 2025, based on 600 breached organisations, measures the effect on breaches.

• One in five organisations reported a breach linked to shadow AI, and those with high levels of it paid on average $670,000 more per breach.
• 97% of organisations with incidents involving AI models or applications had no AI access controls in place.
• 63% of breached organisations had no AI governance policy or were still drafting one, and among those that had one, only 34% regularly audited for unsanctioned AI.

Gartner predicts that by 2030 more than 40% of enterprises will suffer security or compliance incidents linked to shadow AI. In its survey of 302 cybersecurity leaders, 69% suspected or had evidence that employees were using prohibited public generative AI.

Can AI be controlled without holding the business back?

AI can be controlled without holding the business back when the company knows which tools are in use and which data leaves, and the approved route is faster than the unauthorised one. Both extremes come at a cost. Loose control exposes customer data, code or contracts in services the company does not manage and, with personal data, without a processor contract (Article 28 of the GDPR) or a basis for the international transfer. A blanket ban erodes productivity against competitors that do use AI and, as the DBIR's 67% figure for non-corporate accounts suggests, pushes usage into personal accounts that nobody supervises.

An AI committee with business, data protection, legal and security members sets these limits and answers requests for new tools within an agreed time:

• A register of AI use, approved or not, with owner, purpose and data involved, reviewed every quarter against proxy or CASB logs.
• A simple classification of data that may leave, data that may only be used in approved tools and data that must never leave.
• Three tiers of tools (approved, allowed with public data only, and prohibited), with corporate accounts, single sign-on and a contract that excludes training models on company data. Approved tools should cover the most requested uses so the permitted option is also the most convenient one.
• DLP on prompts and uploaded files, with warnings by default and blocks only for data that must never leave.
• Agents, no-code automations and MCP servers entered in the register, with least privilege, expiring tokens, OAuth connections approved by an administrator and a named business owner. Actions that change data or send information outside the company require human approval and are logged, as OWASP recommends.
• Documented training on permitted uses and the risks of each tier, which evidences the AI literacy measures required by Article 4 of the AI Act since 2 February 2025. Since 27 July 2026, Regulation (EU) 2026/1744 keeps that duty without setting a level for each person.

ISO/IEC 42001 provides a management system to organise all of the above, and EU AI Act compliance clarifies which of the company's uses are prohibited or high-risk. Agents with access to internal systems call for a dedicated security audit. The AI security tools in the next table make more sense once that inventory exists.

Which tools and devices make up a typical security stack?

A typical security stack combines perimeter hardware, detection software and cloud services spread across around a dozen layers. The table lists the most common layers and some reference vendors in each.

Firewalls, VPN concentrators and remote access appliances are managed as devices with their own firmware, life cycle and support contracts, and models from several vendors often coexist because of mergers, branch offices or legacy projects. Hardware and software management is as much part of security as detection.

On the plant floor the rules change. Many plant controllers and machines on legacy operating systems cannot run an EDR agent or take frequent patches, and an automated containment can stop a line. Detection relies on passive network monitoring and on zone and conduit segmentation, as the ISA/IEC 62443 series sets out. The SOC contract should exclude automated actions on OT without plant approval.

Can a security tool become the way in?

A security tool can become the way in, because it is also exposed software that needs patching. In the 2025 DBIR, edge devices and VPNs rose from 3% to 22% of vulnerability exploitation actions, with a median of 32 days to full remediation.

Between 2024 and 2025, vulnerabilities in perimeter equipment from Ivanti, Fortinet, Palo Alto Networks, Cisco, Citrix and SonicWall were exploited. In September 2025 CISA issued an emergency directive for Cisco ASA and Firepower firewalls. The Five Eyes agencies published joint guidance on securing edge devices with other partners in February 2025. In FortiGate estates, Fortinet removed SSL VPN tunnel mode in FortiOS 7.6.3 and recommends moving to IPsec, a chance to review who connects remotely and from which devices.

The risk extends to detection platforms too. In 2026 a critical vulnerability in Splunk Enterprise was exploited, and the TeamPCP group compromised open-source security scanners to steal credentials. Each security tool therefore needs an owner and a place in the patching cycle, like any other system.

What does tool sprawl cost?

Tool sprawl costs an average of 5% of annual revenue, according to the executives surveyed by IBM and Palo Alto Networks, as well as response time and the team's attention. According to the same report, organisations with integrated platforms take 72 fewer days to identify an incident and 84 fewer to contain it, with nearly four times the return on investment. These figures come from a study co-produced by a platform vendor.

The most visible cost lies in alerts. A Vectra AI survey of 2,000 security professionals, published in October 2024, found that teams can only deal with 38% of the alerts they receive. 60% believe vendors sell tools that generate too much noise.

On top of that come unused licences, hours spent maintaining integrations and the ingestion cost of a SIEM that stores logs without making use of them. Deciding which logs to send to the SIEM and how long to keep them is often the first saving. Data pipeline platforms such as Cribl or Logstash normalise and route events before the SIEM and send low-value data to cheaper storage, which cuts ingestion costs, although they add another component to maintain.

Single platform or best of breed?

Neither a single platform nor best of breed works as a general rule. A platform cuts consoles, correlates natively and simplifies contracts. In exchange, it ties the company to one vendor, may include modules weaker than the specialist alternative and concentrates risk.

In many companies, part of the platform is already paid for. Microsoft 365 Business Premium includes Defender for Business, Defender for Office 365 Plan 1, Entra ID P1, Intune and Purview, and Microsoft announced that E3 gains Defender for Office 365 Plan 1 features with the July 2026 price rise. The Microsoft Defender Suite add-on, formerly E5 Security, adds Defender for Endpoint Plan 2, Defender for Identity, Defender for Cloud Apps and Entra ID P2. Reviewing those licences is the first lever for retiring overlapping products, although the comparison should count operating hours and accept greater dependence on one vendor.

On 19 July 2024 a faulty CrowdStrike update took down around 8.5 million Windows devices, according to Microsoft. It was not an attack. A content file (Channel File 291) caused an out-of-bounds memory read in the Falcon sensor's kernel driver, and that concentration risk applies as much to a platform as to a specialist product installed on every machine.

Many organisations combine a few platforms with an open data layer. Three standards reduce dependence on a single vendor:

• OCSF, a common schema for logs and alerts backed by AWS, Cisco, IBM and Splunk, which joined the Linux Foundation in November 2024 with some 200 participating organisations.
• Sigma, a detection rule format that converts into queries for Splunk, Microsoft Sentinel, Elastic and QRadar, among others.
• STIX and TAXII, the OASIS standards for describing and exchanging threat intelligence.

Gartner offers three warnings from its 2022 survey, when 75% of organisations were pursuing vendor consolidation, up from 29% in 2020. Cost should not be the main driver, the process takes at least two years and the market is “always consolidating but never consolidated”.

Is the security market consolidating?

The security market is concentrating in a few large groups, and a tool chosen today for its independence may belong to a competitor tomorrow, with changes to its roadmap, pricing or support.

Between 2024 and 2026, Cisco closed its acquisition of Splunk, Palo Alto Networks took over IBM's QRadar SaaS assets and CyberArk, and Google completed its acquisition of Wiz for $32 billion.

Managed services are on the same path: Sophos bought Secureworks in February 2025 and LevelBlue absorbed Trustwave in August 2025. Before signing a long contract, the question to ask is what happens to the data and the rules if the product changes hands.

How can security tool sprawl be reduced?

Security tool consolidation works in phases that follow the renewal calendar, from the inventory and coverage map to measuring the result, without wholesale replacement.

1. Inventory tools, licences, renewal dates, owners, the data each one generates and where that data goes.
2. Map coverage against MITRE ATT&CK and against regulatory requirements, with a single control catalogue for every framework.
3. Identify overlaps (two products doing the same job) and gaps (techniques or requirements left uncovered).
4. Retire unused licences and consolidate as each contract expires, starting with the layers that overlap most, after a parallel run confirms that data sources and detections are preserved.
5. Define a common data layer: which logs are collected, in what format and for how long.
6. Unify evidence so that one control serves NIS2, DORA, the ENS, PCI DSS and ISO 27001.
7. Measure before and after: mean time to detect and respond, percentage of alerts reviewed, number of consoles and cost per protected asset.
8. Document an exit plan for every ICT service that supports critical or important functions, as Article 28(8) of DORA requires of financial entities.

A virtual CISO can lead the process when the company has no full-time security lead.

When does an external cybersecurity provider make sense?

An external provider makes sense when the company cannot sustain integration, 24/7 monitoring and up-to-date detections on its own. A well-chosen MSSP or managed SOC with MDR covers those shortfalls in these areas:

• Integrations, connectors and data normalisation that the provider maintains for many clients and the company does not have to rebuild after every update.
• Analysts who work daily with the tools on the market, on shifts that cover nights and public holidays.
• Detection rules and response procedures updated with what is seen across other clients and intelligence sources.
• Support for reporting incidents within the NIS2 and DORA deadlines, and reports that serve as audit evidence.
• An outside view on which tools to keep, which to retire and how to connect penetration testing and vulnerability management with detection, more reliable when the provider discloses its resale agreements with vendors.

The comparisons of EDR, XDR and MDR and of in-house versus managed SOC help to decide which functions to outsource. In a mid-sized company, the usual split keeps risk management, asset priorities, containment approval, ownership of licences and data, and supplier governance in-house. Outsourcing usually covers 24/7 monitoring, detection engineering, penetration testing and an incident response and forensics retainer agreed in advance.

Is the provider responsible for compliance?

The provider is responsible for what the contract says, while responsibility for compliance stays with the company. DORA states this expressly in Article 28(1)(a): the financial entity remains “fully responsible” even when it outsources ICT services. NIS2 lists supply chain security among the mandatory measures (Article 21(2)(d)), so the security provider is also a third party to be assessed.

NIS2 also lists managed security service providers under “ICT service management (business-to-business)” in Annex I. Medium-sized and large providers fall within its scope through national law (Article 2(1)), and Implementing Regulation (EU) 2024/2690 sets their technical measures.

An external provider can also add to sprawl if it brings its own SIEM and service portal without retiring the company's.

Nor does an outsourced SOC know the business, and without someone in-house to prioritise assets and authorise containment, the service is reduced to forwarding alerts. Ownership of the data, the detection rules and the case history needs settling from day one, along with how they are returned when the contract ends. For critical or important functions, DORA also requires access, inspection and audit rights and a transition period on exit (Article 30(3)). Third-party risk management should cover the security provider like any other supplier.

Which questions help to assess an MSSP or MDR provider?

An MSSP or MDR provider is assessed with questions that force it to put in writing what the sales pitch leaves open:

• Does it work with the tools the company already has, or does it require replacing them with its own?
• Who owns the data, the rules and the cases when the contract ends, and in what format are they handed over?
• What triage and containment times are committed, with what penalties, and which containment actions can it take without prior approval?
• Are the SIEM and EDR licences in the company's name or the provider's, and does it support a co-managed model with in-house access to rules and data?
• How does it support DORA's four-hour initial notification or the NIS2 24-hour early warning?
• Which parts of the service are subcontracted, and to whom?
• Does it accept audits of the service and tests of its exit plan?
• How does it show each quarter, through purple team exercises or attack simulation mapped to MITRE ATT&CK, that coverage is improving and that the number of tools is not growing?
• How does it detect and report a log source that stops sending events?
• Does the monthly report show times by severity, the share of escalated alerts that prove to be incidents, and rules added or retired?
• Which data sources are included in the price, and how is growth in ingestion volume charged?

Where should a company start?

The first step is an honest inventory of tools, licences, renewals and owners, cross-checked against the regulations that apply to the company. For a company of 500 to 1,000 staff, the process usually takes 12 to 18 months.

• In the first quarter, inventory, MFA on all access, perimeter patching, immutable backups with tested restores and a decision on Microsoft licensing.
• Between months 4 and 9, 24/7 monitoring over existing tools and retirement of duplicates as each contract expires.
• Between months 10 and 18, plant segmentation and monitoring, shared evidence for the ENS and NIS2, and a crisis exercise with management.

Budgets compare best as annual cost per employee, adding licences, external service and internal hours. The AI policy can be drafted in parallel, from data on what staff already use.

Outsourcing without that inventory usually shifts the sprawl to the provider. With the inventory in place, the contract can set measurable goals, such as the number of consoles, the percentage of alerts reviewed and the regulatory evidence reused.