The UK Manufacturing Cyber Risk Gap: A Practical Guide for Enterprise IT Teams in UK

Direct answer: A UK manufacturing sector cybersecurity report found that nearly a third of manufacturers were hit by a cyber incident in the past year, and that about half had no incident response plan when it happened. Enterprise IT teams across the UK, not just in manufacturing, should read that as a mirror rather than a headline about someone else's sector, because the underlying cause — response plans that exist on paper but aren't operational, tested, or automated — is a pattern that shows up everywhere IT capacity is stretched thin.

The Make UK cybersecurity report, published in August 2026, is specific about both numbers: close to a third of UK manufacturers reported a cyber incident within the previous twelve months, and roughly half of manufacturers surveyed had no documented incident response plan at all. That combination is the real story. It isn't that manufacturers are being attacked, which surprises no one, and it isn't that a documented plan alone guarantees a good outcome. It's that a sector with meaningful digital maturity and real regulatory pressure still has close to a coin flip's chance of facing an incident with no structured way to respond to it. For an enterprise IT team anywhere in the UK, whether the organisation makes physical products or not, that's a useful benchmark to hold your own environment against, because response-plan gaps are rarely industry-specific — they're a function of how IT teams are staffed, prioritised, and funded, and those pressures look similar across most mid-size and large UK organisations right now.

What the Make UK Report Actually Found

It's worth being precise about what the report says, because it's easy to round two specific numbers into a vaguer, less useful impression. Nearly a third of UK manufacturers experienced a cyber incident in the past year — a twelve-month window, not "at some point in the company's history." That frequency alone tells you incidents in this sector are an operating condition, not a rare event you can reasonably plan around ignoring. Separately, and just as significant, about half of manufacturers had no incident response plan in place. Read together, those two facts describe an environment where getting hit is common and being ready for it is not, and that gap between exposure and preparedness is the actual finding, not either number in isolation.

The report doesn't state why the gap exists, and Scult isn't going to speculate with numbers it doesn't provide. But the shape of the gap is familiar to anyone who has worked inside a busy enterprise IT function. Incident response plans tend to get written once, usually to satisfy an audit, a customer security questionnaire, or a board request, and then sit in a shared drive largely untouched. They reference tools that have since been replaced, escalation contacts who have left the company, and steps that assume someone will remember to run them under pressure, at 2am, while systems are actively failing. A plan like that is functionally the same as no plan, because the moment it's needed is the worst possible moment to discover it's out of date. That's the mechanism, not the manufacturing sector specifically, and it's exactly as present in a services business, a logistics operator, or a financial firm as it is on a factory floor.

There's also a scale point worth sitting with. A third of manufacturers is not a fringe minority — it's a large enough share that, statistically, most enterprise IT leaders reading this either know someone at an affected organisation or run infrastructure connected to one, whether or not they're aware of it. Cyber incidents at this frequency stop behaving like rare, headline-grabbing events and start behaving like a background condition of running digital infrastructure in 2026. Planning for a background condition looks very different from planning for a rare edge case: it means the plan needs to be something the team can execute smoothly and repeatedly, not a document dusted off once every few years in a genuine crisis.

Why This Matters to Enterprise IT Teams Beyond Manufacturing

It would be convenient for enterprise IT leaders outside manufacturing to read the Make UK cybersecurity report, 2026, as someone else's problem and move on. Three things make that reading too narrow.

The Staffing Pressure Is the Same Everywhere

Manufacturing IT teams aren't understaffed or under-resourced in some unique way that other sectors have solved. Enterprise IT teams across retail, logistics, professional services, and the public sector face the identical trade-off: security and incident-response work competes for the same finite headcount as feature delivery, platform migrations, and day-to-day support tickets. When something has to give, incident response planning is disproportionately likely to be the thing that gives, precisely because its cost is invisible until the day it isn't. If a sector as operationally disciplined as UK manufacturing is running at roughly fifty-fifty on having a real plan, there's no solid basis for an enterprise IT team in another vertical to assume its own readiness is meaningfully better, absent an actual audit that proves it.

Vendor and Supply Chain Overlap

Enterprise IT estates rarely stop at the walls of the core business. Hardware suppliers, logistics partners, and industrial or IoT-connected equipment used in warehouses, fulfilment centres, and facilities management frequently trace back to manufacturers — the same population this report is describing. A firmware update channel, a connected sensor fleet, or a vendor support portal is a live link between your network and a third party whose own incident readiness you don't control and usually can't verify. The report's finding about manufacturing isn't sealed inside that sector; it travels through every supplier relationship an enterprise IT team maintains with a manufacturing-adjacent vendor.

The Cost of Being Unready Scales With What You're Protecting

The consequence of an unprepared response is not fixed — it scales with the sensitivity and criticality of what's exposed. A factory without a plan risks production downtime and commercial loss. An enterprise IT environment without one risks customer data exposure, regulatory scrutiny under UK data protection law, contractual breach with enterprise customers who expect documented security posture, and — for organisations running customer-facing digital products — direct damage to revenue-generating systems while nobody is confidently in charge of the response.

That asymmetry is the part worth internalising. A manufacturing line halted for a day is expensive but recoverable in a fairly predictable way. A customer database exposed, or a payment flow left down while a team improvises its first response, carries reputational and regulatory consequences that don't resolve on a predictable timeline at all. Enterprise IT teams protecting exactly that kind of system have less margin for an unprepared response than the sector the report actually studied, which is precisely why treating the finding as a distant industry statistic, rather than a comparable exposure benchmark, understates the stakes.

What Changes in Practice for Your Systems and Response Plan

None of this is a reason to panic about a report that wasn't written about your organisation. It's a reason to treat it as a prompt to check something concrete and answerable: if an incident happened to your systems tonight, would there be a documented, current, tested plan that a specific person could execute immediately, or would the first hour be spent figuring out who's supposed to do what?

Turning a Policy Document Into a Living Playbook

The single most common failure mode behind the "half have no plan" statistic isn't the total absence of any documentation — it's documentation that exists but isn't operational. A PDF that hasn't been opened since it was approved, referencing a tool stack that's since changed, is not meaningfully different from having nothing. The fix isn't writing a longer document; it's making the plan something your team actually works inside of during a live incident: current runbooks, current escalation paths, current contact details, and current system architecture, kept in a place people will actually consult under pressure rather than a compliance archive. This is precisely the gap an AI-powered internal knowledge base is built to close — a system that keeps incident runbooks, escalation contacts, and system documentation current and instantly searchable, rather than static and stale, so the plan is still accurate on the day someone finally needs to open it.

Automating the First 30 Minutes of an Incident

The other half of the fix is speed of the initial response, and this is where most enterprise IT teams have the largest realistic gap to close. Detection is now handled reasonably well across most mature environments — monitoring, alerting, and logging tooling has matured considerably. What's still handled manually, in most organisations, is everything that happens between "an alert fired" and "a human with the right context and authority is actively working the problem": triage, correlation across systems, initial containment steps, and notifying the right people in the right order. Every minute spent on that manual coordination is a minute the incident is unmanaged. This is the specific window where automation earns its cost fastest, because it's a well-defined, repeatable process that doesn't need human judgment to execute the first several steps correctly.

It's also worth widening the lens beyond factory-floor systems. Enterprise IT teams in the UK increasingly own a genuinely diverse digital estate — operational and back-office systems sit alongside customer-facing platforms, including ecommerce storefronts and loyalty programmes that drive repeat revenue. An incident response gap doesn't respect those boundaries: the same missing playbook that leaves a production system exposed will just as easily leave checkout, account, or points-redemption flows down during an incident, which is a direct hit to the kind of retention mechanics covered in our guide to ecommerce loyalty programs. A response plan worth having covers the full estate, not just the systems that feel most obviously "critical infrastructure."

In practice, this means the exercise of mapping out a response plan can't be delegated purely to whichever team owns "security" in the org chart. It needs input from whoever owns the customer-facing platforms, whoever owns operational and facilities systems, and whoever owns core infrastructure, because each of those groups has a different view of what "critical" means and a different set of dependencies that the others won't naturally think to include. Skipping that cross-functional step is one of the quieter reasons plans end up incomplete even when someone did genuinely sit down and write one.

Where AI Agents and Automation Fit Into Closing the Gap

The reason this trend sits squarely in automation, rather than purely in policy or headcount, is that the manual version of a good incident response process doesn't scale to how often incidents actually happen. If nearly a third of a comparable sector is getting hit annually, a response process that depends on a specific senior engineer being awake, available, and correctly informed is not a plan — it's a hope. AI Agents & Automation exists as a service category precisely for this kind of problem: repeatable, rules-plus-judgment workflows that need to run consistently regardless of who's on call.

In practice, this looks like an agent that watches monitoring and alerting output, correlates related signals instead of firing twenty disconnected pages for one root cause, checks the current runbook for the matching scenario, executes the safe first-response steps automatically — isolating an affected service, rotating a credential, disabling a compromised integration — and then escalates to a human with a pre-assembled summary instead of a raw alert stream. None of that replaces the judgment calls that still need a person. What it removes is the slow, error-prone manual coordination that currently eats the first critical minutes of almost every incident, which is exactly the window where an unprepared organisation loses the most ground. Our AI Agents & Automation work is built around this shape of problem: connecting monitoring, documentation, and communication tools so the first response steps happen automatically and consistently, rather than depending on whoever happens to be paying attention when the alert fires.

The scoping question most enterprise IT teams get wrong at this stage is trying to automate everything at once. A better starting point is picking the single alert category that currently costs the most manual coordination time — often something like a suspicious authentication pattern, an unexpected data export, or a third-party integration failure — and building the automated triage-and-response flow for that one scenario first. That gives the team a working, tested example to point to, surfaces integration issues on a small scale before they compound across the whole estate, and creates the template the rest of the response plan can be built out from, rather than trying to design a complete system before anything is running.

There's a supporting-tooling angle worth naming too. Many enterprise IT teams are also modernising how field engineers, facilities staff, or on-site technicians report and escalate issues, particularly across distributed sites where a browser-based tool isn't practical. Where that modernisation includes a purpose-built mobile app for incident reporting or on-call coordination, cross-platform frameworks are usually the pragmatic choice for shipping to both iOS and Android without doubling the build effort — our breakdown of Flutter app development covers when that trade-off makes sense versus native development, which is a relevant decision if a mobile incident-reporting tool is part of your response plan upgrade.

What This Kind of Work Typically Costs

A precise, universal price for "fixing your incident response gap" doesn't exist, because the starting point varies enormously — some enterprise IT teams have a decent plan that just needs automating, others are closer to the "no plan at all" half of the Make UK finding. What's useful is understanding which tier of engagement this kind of work typically falls under, based on scope.

Tier	Typical scope for this work
Essential – $1,000	Automating a single, well-defined alert-to-escalation workflow, or standing up a first version of a searchable incident runbook
Growth – $2,000	Connecting monitoring, documentation, and communication tools into a coordinated automated triage-and-escalation flow across several systems
Enterprise – $4,000+	Full AI agent orchestration across a multi-system IT and operational estate, with custom compliance reporting and integration into existing security tooling

Most enterprise IT teams starting from a genuine gap — rather than a partial system that needs extending — will find their real scope sits in the Growth tier once monitoring, documentation, and escalation are all brought into one coordinated flow rather than handled as separate projects. It's also worth budgeting the work in stages rather than as one all-or-nothing decision. Starting at Essential to prove the approach on one workflow, then expanding into Growth once that first automation is running reliably, is usually a more realistic path than trying to fund a full Enterprise-scale rebuild of incident response in a single approval cycle — particularly for IT teams that also have to justify the spend against competing priorities on a limited annual budget.

Key Takeaways

• The Make UK cybersecurity report, 2026, found nearly a third of UK manufacturers hit by a cyber incident in the past year, with about half lacking an incident response plan.
• The staffing and prioritisation pressures behind that gap aren't manufacturing-specific — they're present across most UK enterprise IT teams to some degree.
• A response plan that exists but is out of date is functionally equivalent to having no plan at all.
• The highest-leverage fix is automating the first response window — triage, correlation, and initial containment — rather than only writing better documentation.
• An AI-powered internal knowledge base keeps runbooks and escalation paths current enough to be trustworthy during a live incident.
• Treat this as a prompt to audit your own environment now, before an incident forces the audit for you.

If you're not certain whether your organisation would be in the prepared half of that split or the exposed half, that uncertainty is worth resolving before an incident does it for you — book a meeting with our team to talk through what closing that gap would actually take for your systems.

Frequently Asked Questions

What exactly did the Make UK cybersecurity report find?

It found that nearly a third of UK manufacturers had experienced a cyber incident in the past twelve months, and that roughly half of manufacturers surveyed had no documented incident response plan in place. Both figures come from the Make UK cybersecurity report, published in August 2026.

Does this report apply to enterprise IT teams outside manufacturing?

The report itself is specific to UK manufacturing, but the underlying cause of the gap — response plans that are outdated, untested, or simply never written — is a staffing and prioritisation pattern common across most UK enterprise IT functions, not something unique to manufacturing. Treat it as a reasonable benchmark for your own environment rather than a manufacturing-only finding.

Why would a sector as regulated as manufacturing still lack incident response plans?

The report doesn't state a specific cause, so it would be wrong to invent one. What's observable in most organisations, regardless of sector, is that incident response work competes for the same limited IT capacity as feature delivery and daily support, and its absence has no visible cost until an incident actually happens.

What counts as a real incident response plan versus a document that doesn't count?

A real plan names specific current systems, specific current escalation contacts, and specific first-response steps that someone can execute immediately under pressure. A document that references retired tools, former employees, or vague guidance like "notify the appropriate stakeholders" is not operational, even if it technically exists in a shared drive somewhere.

How common is it for a written plan to be effectively useless in practice?

There's no UK-specific figure available for this exact question, but it's a well-documented pattern generally: plans written once for an audit or customer questionnaire and never revisited tend to go stale within a year or two as tools, staff, and architecture change underneath them.

What's the single biggest gap enterprise IT teams should check first?

Whether the current incident response plan references your actual, current toolset and actual, current on-call contacts. If either has changed since the plan was last reviewed, the plan should be treated as unreliable until it's updated and tested.

How does this connect to AI Agents & Automation specifically?

Incident response has a well-defined first phase — detecting, correlating, and triaging an alert, then executing initial containment steps — that doesn't require human judgment to execute correctly, which makes it a strong fit for automation. AI Agents & Automation work in this area focuses on connecting monitoring, documentation, and communication tools so that phase happens consistently without depending on whichever person happens to be on call.

What does an AI agent actually do during a live incident?

In a typical setup, it watches monitoring output, groups related alerts that share a root cause instead of triggering a flood of separate pages, checks the relevant runbook, executes safe first steps like isolating an affected service or disabling a compromised integration, and hands a human a summarised, contextualised escalation rather than a raw alert feed.

Does automation replace the need for human decision-making during incidents?

No. Automation handles the repeatable, well-defined first steps so a human isn't starting from zero, but judgment calls about scope, communication, and remediation strategy still need a person with authority and context. The goal is removing the slow manual coordination that currently delays that person from getting involved effectively.

How long does it typically take to build this kind of automated incident workflow?

Timelines scale with scope: a single automated alert-to-escalation workflow is a matter of weeks, while a coordinated flow spanning monitoring, documentation, and communication tools across multiple systems takes longer because it depends on how many existing tools need to be integrated cleanly.

What does this kind of work typically cost?

It typically falls into three tiers depending on scope: Essential at $1,000 for a single automated workflow or a first version of a searchable runbook, Growth at $2,000 for a coordinated triage-and-escalation flow across several systems, and Enterprise at $4,000+ for full AI agent orchestration across a multi-system estate with custom compliance reporting.

Which pricing tier fits a team with no incident response plan at all?

Most teams starting from genuinely nothing will find their real scope sits closer to the Growth tier, because connecting monitoring, documentation, and escalation into one coordinated flow — rather than treating each as a separate later project — is what actually closes the gap the Make UK report describes.

What is an AI-powered internal knowledge base and how does it relate to incident response?

It's a system that keeps internal documentation — runbooks, escalation paths, system architecture notes — current and instantly searchable, rather than static and gradually outdated. For incident response specifically, it's the mechanism that keeps a plan operational instead of letting it decay into the kind of stale document the Make UK report's "no plan" statistic is really describing.

Can an existing outdated incident response plan be automated as-is?

Not usefully. Automating an out-of-date plan just executes the wrong steps faster. The plan's content — current tools, current contacts, current architecture — needs to be accurate first, which is usually done alongside building the knowledge base and automation together rather than as separate sequential projects.

What UK regulatory bodies care about incident response readiness?

The Information Commissioner's Office expects organisations handling personal data to have appropriate technical and organisational measures, which includes incident response capability, and UK organisations in critical sectors may also face sector-specific reporting obligations. Specific enforcement thresholds and timelines vary by sector and data type, so this is worth confirming against your own regulatory obligations rather than treating as one-size-fits-all.

Is there a legal requirement in the UK to have a documented incident response plan?

Requirements vary significantly by sector, data type, and organisation size, and there isn't a single blanket UK law mandating a specific plan format for every business. What's consistent is that data protection obligations under UK law expect organisations to be able to respond to and report incidents appropriately, which in practice is very difficult without a documented, current plan.

How does supply chain risk connect manufacturing's cyber gap to non-manufacturing enterprise IT teams?

Many enterprise IT estates include hardware, connected devices, or equipment sourced from manufacturers, and those relationships create live links — firmware updates, vendor support portals, connected sensor fleets — between the enterprise network and a third party's own security posture. If that manufacturer sits in the roughly one-in-three hit by an incident, or the roughly half with no response plan, the enterprise IT team on the other end inherits exposure it doesn't directly control.

Should an enterprise IT team audit its manufacturing and hardware vendors specifically?

It's a reasonable, low-cost step: knowing which vendors supply connected hardware or equipment, and whether those vendors have documented incident response practices, gives you visibility into a risk category that's easy to overlook because the relationship feels like a one-time purchase rather than an ongoing software dependency.

What happens to customer-facing systems like ecommerce or loyalty platforms during an unmanaged incident?

They're exposed the same way any other system is — an incident response gap doesn't stop at operational or back-office systems. If checkout, account access, or points-redemption flows go down during an unmanaged incident, the damage compounds quickly, because those systems are also where the retention behaviour built through programmes like ecommerce loyalty schemes actually lives.

Why should loyalty and ecommerce systems be included in an incident response plan?

Because they're often the most visible systems to customers, and an outage or breach there does direct, immediate damage to trust and repeat-purchase behaviour, on top of whatever technical or financial cost the incident itself causes. A response plan that only covers internal or operational systems leaves exactly the systems customers notice most unprotected.

What's the risk of treating this report as manufacturing-only and ignoring it?

The risk isn't that the report is wrong about manufacturing — it's that dismissing it as irrelevant skips the useful exercise of checking your own readiness. Given how common the staffing pressures behind the gap are across UK enterprise IT generally, that's a costly assumption to get wrong.

How does an enterprise IT team know if it's in the "prepared half" or the "exposed half"?

The only reliable way to know is an actual audit: pulling the current incident response plan, checking whether it names current tools and current contacts, and ideally running a tabletop exercise to see whether the team can execute it under simulated pressure. Assuming readiness without testing it is exactly the gap the Make UK report is describing.

What's a tabletop exercise and why does it matter here?

It's a structured walkthrough where the team simulates responding to a specific incident scenario using the actual current plan, without it being a real event. It surfaces exactly the kind of gaps — outdated contacts, missing steps, unclear ownership — that turn a plan that looks fine on paper into one that fails under real pressure.

Can smaller enterprise IT teams realistically implement this kind of automation?

Yes — this is precisely why tiered engagement makes sense. A smaller team can start with a single automated workflow around their highest-risk alert category at the Essential tier and expand coverage over time, rather than needing to solve the entire incident response problem in one project.

What existing tools does an AI agent for incident response typically connect to?

Typically monitoring and alerting platforms, ticketing or incident management tools, internal documentation or knowledge base systems, and communication tools like chat or paging systems. The specific integration set depends entirely on what an organisation already has in place.

Does adding automation to incident response increase security risk itself?

Any new system that can take automated actions — isolating a service, rotating a credential — needs to be scoped carefully with appropriate permissions and audit logging, so it doesn't become its own point of failure. This is a standard part of designing the automation properly rather than a reason to avoid it.

How does this trend relate to AI Agents & Automation as a broader category, beyond just security?

Incident response automation is one specific, high-value application of the same underlying approach used across AI Agents & Automation work generally: taking a repeatable, well-defined process that currently depends on manual coordination and making it run consistently without a person needing to execute every step by hand.

What's the difference between monitoring/alerting tools and incident response automation?

Monitoring and alerting tell you something is wrong. Incident response automation is what happens after that alert fires — correlating it with related signals, checking the right runbook, executing safe first steps, and escalating with context. Most enterprise IT teams already have strong tooling for the first part and a manual, ad hoc process for the second.

Is this report likely to be followed by similar findings in other UK sectors?

There's no way to know that with certainty, and it would be speculation to claim otherwise. What can be said reasonably is that the underlying pressures — stretched IT capacity, documentation that goes stale, response plans written once and rarely revisited — aren't unique to manufacturing, so it wouldn't be surprising if similar patterns exist elsewhere, even without a specific report confirming it yet.

Should an enterprise IT team wait for a similar report about its own sector before acting?

No — the value of the manufacturing finding is that it gives you a concrete, credible reason to check your own readiness now, rather than waiting for a sector-specific statistic that may or may not ever get published for your particular industry.

What role does a mobile incident-reporting app play in closing this gap?

For enterprise IT teams with distributed sites, field engineers, or facilities staff, a purpose-built mobile app can meaningfully speed up how quickly an issue gets reported and escalated in the first place, which matters because automation can only act on an incident once it's actually been flagged.

Why would Flutter specifically be relevant to building that kind of app?

Flutter allows a single codebase to ship to both iOS and Android, which is typically the pragmatic choice for an internal tool like incident reporting where the goal is broad staff coverage quickly rather than a highly platform-specific experience. It's worth weighing against native development based on your team's specific requirements and existing skills.

What's the first practical step an enterprise IT team should take after reading this?

Pull the current incident response plan, if one exists, and check three things: does it name your actual current tools, does it name people still at the company in the roles listed, and has anyone actually tested it. If any of those fail, that's the starting point, not a full automation project.

How does an AI-powered knowledge base stay current instead of going stale like a typical document?

It's built to be actively maintained and searched as part of normal workflow, rather than filed away after one-time approval, so updates to systems, contacts, or procedures are more likely to be reflected in it because people are actually using it rather than only opening it during an audit.

Can existing documentation be migrated into a new knowledge base, or does it need to be rewritten?

Existing documentation is usually a reasonable starting point and doesn't need to be thrown away, but it does need to be reviewed for accuracy during migration, since the whole point is ensuring what's in the system reflects current reality rather than carrying forward the same staleness in a new format.

What's the risk of over-automating incident response?

The main risk is giving an automated system authority to take actions — like isolating production services — without sufficiently tight scoping, testing, and human oversight for higher-impact steps. Automation should extend confidently into well-understood, low-risk first steps and hand off deliberately to a human for anything with broader consequences.

How does this affect enterprise IT teams that already have decent monitoring in place?

Good monitoring is necessary but not sufficient — it solves detection, not response. Many enterprise IT teams with strong alerting tooling still have exactly the gap this report describes, because the process after the alert fires is still manual, which is the specific problem automation is positioned to solve.

What does "half lacking an incident response plan" imply about the average time to respond?

The report doesn't give a specific response-time figure, so it would be wrong to invent one. What can reasonably be inferred is that an organisation improvising its response for the first time during a live incident will almost always be slower and more error-prone than one executing a tested, current plan.

Is this more urgent for larger enterprises or smaller ones?

Exposure scales with what's being protected rather than purely with company size — a smaller enterprise handling sensitive customer data can be just as exposed as a larger one, and in some cases has fewer resources to absorb an unmanaged incident, so size alone isn't a reliable indicator of how urgent this is.

How does this connect to cyber insurance for UK enterprises?

Many cyber insurance policies expect evidence of reasonable security practices, which increasingly includes a documented incident response capability; a gap here can affect both the availability and terms of coverage, though specific policy requirements vary by insurer and should be checked directly rather than assumed.

What's a realistic first automation project for a team with limited budget?

Automating triage and escalation for the single highest-frequency or highest-risk alert category is usually the most efficient starting point, because it delivers a concrete reduction in manual coordination time without requiring the full estate to be connected at once.

How do you measure whether incident response automation is actually working?

Practical measures include the time between an alert firing and a human being actively engaged with full context, and how consistently the correct first-response steps get executed regardless of who's on call. Both are observable improvements over a manual baseline without needing invented benchmark figures.

Does this apply equally to cloud-based and on-premises enterprise IT environments?

The underlying pattern — response plans that go stale, manual coordination eating the first critical minutes — applies to both, though the specific tooling and integration points for automation differ depending on whether systems are cloud-hosted, on-premises, or a hybrid of the two.

What's the relationship between this trend and general AI adoption in UK enterprise IT?

It's a specific, well-scoped application of the same broader shift enterprise IT teams are already navigating: moving repeatable operational processes from manual execution to automated, AI-assisted workflows, starting with the processes where the cost of manual delay is highest.

How should an enterprise IT team prioritise this against other AI and automation projects?

Incident response automation has a strong case for early prioritisation specifically because the cost of inaction is asymmetric — most automation projects improve efficiency, but this one directly reduces exposure to the kind of incident nearly a third of a comparable UK sector is already experiencing annually.

What happens if an incident response plan exists but has never been tested?

An untested plan carries meaningful uncertainty about whether it actually works, similar in effect to having a weaker plan than assumed, because gaps in a plan are far more likely to surface during a real incident than during casual review. Testing it, even informally, is a low-cost way to close that uncertainty before it matters.

Is it possible to build this automation without changing existing monitoring tools?

In most cases yes — the goal is typically connecting to existing monitoring, documentation, and communication tools as they are, rather than replacing them, since the automation layer sits on top of and coordinates between systems the team already relies on.

How does data sensitivity change the priority of fixing this gap?

Organisations handling sensitive personal data, financial information, or health data carry higher consequences for an unmanaged incident, which raises the priority of closing the gap even if the organisation's overall cyber incident frequency turns out to be similar to any other sector.

What's the honest limitation of this report for non-manufacturing readers?

It's honestly a manufacturing-specific data set, and it would be inaccurate to claim it proves the same exact percentages apply to other sectors. Its real value for enterprise IT teams elsewhere is as a credible prompt to check comparable readiness in their own environment, not as direct evidence about their specific sector.

Where does Scult fit into addressing this gap for an enterprise IT team?

Scult's AI Agents & Automation service is built for exactly this kind of problem — connecting monitoring, documentation, and communication systems so that incident detection, triage, and initial response happen automatically and consistently, alongside keeping the underlying documentation current through an AI-powered internal knowledge base. Bringing whatever current incident response documentation exists, even if it's known to be outdated, along with a list of the core monitoring and communication tools already in use, is usually enough to scope the right starting tier accurately.