AI-ready cyber resilience starts with technology intelligence

Back in April, JPMorganChase published Fortifying the enterprise: 10 actions to take now for AI-ready cyber resilience, outlining practical steps enterprises should take as AI accelerates both technology development and cyber threats.

Since then it's become a piece we've referenced behind the scenes in conversations with enterprise technology leaders, prospects and customers alike.

The reason is simple, many of the recommendations reflect challenges we hear about every day:

• Run current software. 
• Maintain a continuously updated inventory. 
• Enrich asset records with better context. 
• Understand SaaS and outsourced dependencies. 
• Move faster when risk and vulnerabilities emerge. 
• Monitor AI embedded within third-party software.

These may look like distinct technology and security initiatives. But during our discussions, we've kept coming back to the same underlying requirement: Before an enterprise can act faster, it needs to understand its enterprise wide technology portfolio faster.

Organizations need to know what technology they have. What it does at its core. Which versions are running. Where it is used. What business functions depend on it. Which vendors and services introduce dependencies. Where AI is embedded. And what has changed.

JPMorganChase puts the problem succinctly: “You cannot fix what you don't know about.”

After repeatedly coming back to this article in conversations, we thought it was worth bringing that discussion into the open. Knowing what you have is only the beginning. AI-ready cyber resilience increasingly requires continuously monitored and updated technology intelligence that provides the context to understand where change or risk matters.

Running current software requires knowing what you're running

One of JPMorganChase's first recommendations is deceptively simple: run the latest software versions.

The article recommends treating technical debt as an immediate priority, tracking end-of-life timelines and moving unsupported operating systems and enterprise software onto supported releases.

At enterprise scale, that can be easier said than done.

Technology estates contain thousands, sometimes tens of thousands, of applications. The underlying records may use inconsistent vendor and product names. Version information can be incomplete. Lifecycle data changes. Ownership may be unclear or missing. And multiple repositories can contain conflicting information about the same technology.

An end-of-life date isn't particularly useful on its own. The value comes from connecting it to the enterprise to understand the true risk implication: 

Product → Deployed version → Latest version → EOL/EOS status → Business context → Owner → Required action

That turns lifecycle data into actionable intelligence.

Rather than discovering unsupported technology during an audit, a vulnerability event or an upgrade project, enterprises should be able to continuously identify where deployed versions are falling behind and where upcoming lifecycle events require proactive planning and action. 

Technical debt becomes easier to manage when you can easily see it.

An inventory isn't the same as technology intelligence

JPMorganChase also recommends maintaining a comprehensive, continuously updated inventory of hardware, software and cloud assets, including shadow technology and developer-provisioned resources.

Importantly, the recommendation doesn't stop at inventory. Organizations should enrich asset records with additional context, integrate that information into vulnerability and incident response workflows, and continuously reconcile inventories with discovery scanning. The goal is to answer a critical question when a new threat appears: Where are we exposed?

This is one of the recommendations that resonates most with the conversations we're having. Most large enterprises don't have a lack of technology data. Quite the opposite. They have CMDBs, ITAM, SAM and HAM platforms, EA repositories, spreadsheets, discovery tools and other sources containing different pieces of the picture.

The challenge is turning all of that data into a consistent understanding of the technology estate. Discovery can tell you that something exists. A CMDB can record it. An ITAM or SAM platform can help manage it. But making architecture, risk and remediation decisions requires understanding what that technology actually is.

What product does an inconsistent vendor record represent? What core capabilities does it provide? Is it commercial, open source or developed in-house? What is its current lifecycle status? Does it contain AI functionality? What other technologies provide the same capabilities?

That requires another layer of context. At Entrio, we think of the progression this way:

Discover → Normalize → Classify → Enrich → Add enterprise context → Decide

Existing enterprise systems remain essential. The opportunity is to continuously improve the intelligence flowing through them. That is the difference between maintaining an inventory and having an understanding of your technology estate that accelerates decision velocity.

Dependency risk is difficult to see from a vendor list

Another JPMorganChase recommendation is to maintain a current register of SaaS, cloud and outsourced service providers supporting critical business functions, then share that information across technology, risk and business continuity teams.

The objective is to make concentration risk and potential failures visible before an incident occurs. Again, the underlying data matters. Knowing that an enterprise uses a particular vendor is useful. Knowing which solutions it uses is better. Understanding the business functions those solutions support provides another level of insight.

Consider the difference between:

Vendor → Solution

and:

Vendor → Solution → Technology capabilities → Business function → Organizational usage

The second view can begin to reveal where multiple critical functions depend on the same provider, where alternative solutions exist, and where concentration may create greater operational exposure than a vendor inventory alone would suggest.

This is one reason technology classification matters beyond enterprise architecture.

A granular, consistently applied taxonomy creates a common language for understanding what technology actually does across systems, regions, and business units. For many organizations, applying a “capability” based taxonomy is a significant shift because it enables broader search and rationalization opportunities.

Faster remediation requires faster understanding

JPMorganChase also argues that traditional change processes need to accelerate. Organizations should examine the complete journey of a security patch from vendor release through production deployment and identify the approvals, testing queues, and other handoffs creating unnecessary lag.

Technology intelligence doesn't replace patch management, vulnerability management, or change management.

But it can eliminate another source of latency: figuring out what the organization needs to act on in the first place.

When a vulnerability, end-of-life event or significant vendor change occurs, teams shouldn't have to begin by asking:

• Do we use this technology?
• Which product is actually affected?
• Which versions are deployed?
• Where is it used?
• What capabilities depend on it?
• Who owns it?
• What alternatives do we already own?

The answers should already be available. Reducing time-to-action starts by reducing time-to-understanding.

That's relevant well beyond cybersecurity. It's the same data challenge we see slow architecture decisions, rationalization programs, technology evaluations, audit responses, and governance initiatives.

When teams have to reconcile spreadsheets, inconsistent product names and fragmented repositories before they can answer a question, the decision itself isn't necessarily the slow part. Establishing the facts and context  is.

AI supply chain risk extends beyond the AI tools you approved

Perhaps the most interesting recommendation in JPMorganChase's article concerns AI itself. The authors recommend assessing and monitoring third-party AI services and embedded AI features in SaaS platforms, arguing that AI supply chain risk should be treated as an extension of software supply chain risk.

That distinction deserves more attention. Most organizations can identify the obvious AI technologies they have intentionally purchased or approved. The harder question is: Which products already in our technology portfolio have introduced AI capabilities?

A SaaS application that went through procurement two years ago may look very different today. Vendors are continuously introducing copilots, generative AI, autonomous capabilities and other AI functionality into existing products. That means AI can enter the technology estate without the enterprise adopting a new product, via an innocent upgrade. 

This expands the traditional definition of Shadow AI. Shadow AI isn't limited to employees adopting unapproved AI tools. It can also emerge when approved software introduces AI capabilities the enterprise isn't yet tracking.

Point-in-time questionnaires and annual inventories struggle with this problem because the underlying products are changing continuously. Current processes often rely on vendor self-reporting, which is known to be inconsistent and not timely. Organizations increasingly need to understand:

Solution → AI present → Core capability or feature → AI use case → Supporting evidence → Changes over time

This doesn't replace AI governance, third-party risk management or cybersecurity assessment functions. It gives those workflows a more complete view of where they should be looking.

The common requirement: a living understanding of technology

Months after JPMorganChase published its recommendations, I keep coming back to the same takeaway in conversations with enterprise prospects and customers.

The organizations we speak with aren't short on systems, data or expertise. The challenge is getting the right technology information, with the right context, to the people making decisions so they can quickly take action.

Cybersecurity platforms still need to detect and remediate threats. Discovery tools still need to find technology. CMDBs, ITAM platforms and enterprise architecture repositories remain important systems of record. But the effectiveness of all of them depends on the quality and context of the technology information underneath the decision.

That's where technology intelligence becomes increasingly important.

Entrio continuously cleans, normalizes, enriches and classifies enterprise technology data, while maintaining an evolving reference catalog of technology available in the market. That intelligence can help organizations understand deployed versions, proactively plan for lifecycle risk, map technologies to capabilities, identify dependencies and monitor AI functionality added to existing solutions across the portfolio.

The objective isn't another inventory or another system competing to become the source of truth. It's a living understanding of the technology estate so the teams responsible for managing it become more effective.

JPMorganChase's recommendations are worth revisiting as the underlying challenge is only getting worse and becoming more urgent. If AI is compressing the time between vulnerability and exploitation, enterprises need to compress the time between knowing something has changed and knowing how it affects the organization. 

From the conversations we're having, closing that gap is becoming an increasingly important part of building a more resilient technology estate. And it starts with better technology intelligence.