In April 2026, JPMorganChase's Global Technology Leadership Team published Fortifying the enterprise: 10 actions to take now for AI-ready cyber resilience. In July Michael Cembalest's Patchmageddon paper restated all ten points and put numbers behind them: 48,185 vulnerabilities disclosed in 2025 against roughly 7,500 patched, and a median time-to-exploit that has fallen from a year to a day.
When the largest bank in the world publishes a cyber resilience checklist, two kinds of company should read it carefully. The banks it is written for. And the suppliers those banks depend on.
Cutover is both a supplier to tier-1 financial institutions and the orchestration layer many of them use to respond to major incidents and recover from cyber events. So we read the ten actions twice: once asking how our platform helps customers execute them, and once asking whether we meet them ourselves.
Here are our thoughts. Including the actions that are honestly not our lane.
1. Run the latest software versions
What JPMorganChase asks. Treat technical debt reduction as an immediate priority with senior oversight. Replace hardware before end-of-life. Upgrade unsupported operating systems, enterprise software and open-source dependencies to supported releases.
The execution problem inside it. Nobody disputes the goal. The blocker is that a large-estate upgrade programme is thousands of coordinated changes across teams who each have a reason to wait. Patchmageddon notes that the median open-source dependency is now 278 days behind its latest major version, and that 90% of codebases rely on obsolete components in some form.
How Cutover responds. Upgrade waves run as orchestrated runbooks with dependencies, owners and rollback baked in. One multinational investment company moved from taking environments down one at a time to updating hundreds of environments in a single weekend, with Ansible jobs triggered directly from Cutover tasks, saving an estimated $480,000. A global payments team orchestrating 29,000 changes cut failed or delayed changes by half.
Cutover’s own posture
We subscribed to the “broken windows theory” for our dependencies in that if we start to fall behind it would become acceptable to fall behind with patch management and software. So since our founding we have taken a zero tolerance approach to Critical + High CVEs in our core software product. This has gotten harder as time has gone by and the amount of exploits has increased. But still today any CVE will stop our development team's ability to merge to our trunk branch and make sure all our “windows” are repaired.
2. Manage assets and software components with reference data
What JPMorganChase asks. A continuously updated inventory of hardware, software and cloud assets. A software bill of materials (SBOM) for every application. Asset data integrated into vulnerability management, change management and incident response workflows.
The execution problem inside it. That last line is the one to notice. Inventory only has value when the response and change process actually uses it under pressure. TuxCare's 2026 survey, quoted in the paper, lists "lack of a common view of apps and assets" and "reliance on emails and spreadsheets to manage the process" among the top causes of patching delay.
How Cutover responds. Cutover is not a CMDB and does not try to be. Runbooks bind to the configuration items in your system of record through the bi-directional ITSM integrations, so when a P1 opens, the runbook already knows which applications, owners and dependencies are in scope. Data-collection agents can pull recent changes on the affected CIs before a human is even on the bridge.
Cutover’s own posture
Cutover has an automated process which produces an SBOM of all dependencies for our core product, on every change to the codebase. This process is integrated into our CI/CD pipelines. For every release we ship, we can trace back exactly which dependencies make up that version of our software.
For our platform we also have a biweekly update on the current state of our core software for things like Ruby & Java end of life that we know would be more problematic to update if we are not careful.
3. Build and operate a robust vulnerability management programme
What JPMorganChase asks. Fix known vulnerabilities in order of criticality. Establish SLA-driven remediation timelines. Report vulnerability ageing and remediation velocity to senior leadership. Treat persistent exceptions as risk acceptances requiring executive accountability.
The execution problem inside it. In around 60% of breaches, a patch was already available. Over 80% of security professionals have forgone patching to avoid disrupting the business. And 80% of CIOs and CISOs have been surprised to find a patch they believed fully deployed had not reached every device.
How Cutover responds. We are not a scanner and do not prioritise vulnerabilities. What we add is the remediation velocity number itself, measured from the execution record rather than from ticket closure. When a critical patch runs as an orchestrated wave, every target, owner and completion state is timestamped. "Deployed" means verified, not assumed. That is the number leadership should be reporting.
Cutover’s own posture
This one is covered, in how we handle our software versions and the same applies, we are just aggressive in checking particularly for our fast moving frameworks that provide our APIs and protect our data we are keeping up to date and current.
4. Stress test incident response and resiliency plans
What JPMorganChase asks. Tabletop exercises and live simulations for destructive attacks, ransomware and supply chain compromise. Full restoration tests of critical systems. Senior business, legal and third-party stakeholders in the room. Track and fix findings with rigour after every exercise.
The execution problem inside it. Most exercises are run in a different environment, with different tooling, from the one the team will respond in. The time signal they produce cannot be trusted. And findings go into a slide deck where they die.
How Cutover responds. This is the lane Cutover was built for. A top-five bank has built over 1,000 automated runbooks and completed more than 30 cyber recovery exercises for bare-metal recovery scenarios. A multinational bank cut recovery testing time from 12 weeks to two across 5,000 services. Because the exercise and the live response run through the same runbooks, the rehearsal is the response. Findings become tasks with owners, not actions on a page.
Cutover’s own posture
Aside from privacy and security benefits, our single tenant architecture means we are well rehearsed in building entirely new application instances from bare metal. This gives us a well oiled machine for performing a full restoration of critical systems in the event of a destructive attack.
5. Know your major SaaS and outsourced dependencies
What JPMorganChase asks. A current register of every SaaS, cloud and outsourced provider supporting critical functions. Security posture and incident response assessments of each. Contractual requirements for notification, audit rights and recovery objectives. Contingency and exit plans.
The execution problem inside it. Two, actually. Enterprises need to respond when a critical provider fails. And suppliers need to be able to answer these questions without a six-week scramble.
How Cutover responds as your platform. Third-party outages are incidents like any other and get runbooks like any other. When a 35.5-hour regional AWS failure struck, a leading American financial institution used Cutover to execute over 200 coordinated recovery tasks across an 1,800-person global team, with an immutable audit log generated for regulators as it ran.
How Cutover responds as your supplier. Cutover runs as SaaS outside the customer's network, which is precisely why banks reach for it during cyber recovery when internal systems are compromised. That also makes us one of the dependencies this action is about.
6. Optimise change management for speed
What JPMorganChase asks. Map the end-to-end patch lifecycle from vendor release to production. Invest in automated testing, staged rollout and rollback. Establish emergency change pathways that bypass non-essential gates while maintaining auditability. Measure and report mean time to patch as a key operational metric.
The execution problem inside it. "Fast" and "auditable" are treated as a trade-off in most enterprises because the audit record is assembled after the fact. The faster the change, the thinner the record.
How Cutover responds. This is the second core lane. When the change runs as a runbook, the audit trail is a by-product of execution: every task, approval, script run and rollback decision is timestamped as it happens. The emergency pathway and the auditable pathway become the same pathway. Mean time to patch stops being an estimate and becomes a measurement.
Cutover clients demonstrated roughly 53% faster recovery times on IT disaster recovery before extending the same model to change and incident response. The pedigree is orchestration under pressure.
Cutover’s own posture
Cutover has invested heavily in automated testing and patch management. Using open source and vendor supplied tools, our codebases are continuously scanned for vulnerable dependencies. Our checks and controls mean software exposed to vulnerable dependencies cannot be shipped.
This forces us to upgrade at the earliest opportunity, and our automated test suites verify the correct behaviour of our software after our upgrades. This allows us to ship emergency changes to customers in a fast, repeatable way, and with confidence.
7. Aggressively filter outbound traffic from production systems
What JPMorganChase asks. Allow-list-based outbound filtering for production. Default-deny rather than block-known-bad. Monitor anomalous egress. Test and maintain rules as part of change management.
Where Cutover stands. This is a network control. We do not sell it and will not pretend the platform delivers it. However rolling out default-deny across a live production estate is itself one of the highest-risk change programs a bank can run, and it needs the same sequencing, rollback and execution record as any other.
Cutover’s own posture
We actually block all outbound requests for integrations via Cutover Connect, an on-prem application. HTTP requests to downstream services are tightly controlled by our customers' administrators which means 'As Cutover sees Connect' it has no operational visibility of authentication mechanisms or credentials. HTTP requests and associated authentication mechanisms to downstream services operate using an allow-list configuration file based model with strong parameters, also layering in Kerberos for secure internal network requests.
8. Remove standing privileges from employee entitlements
What JPMorganChase asks. Privileged access management with vaulted credentials and just-in-time provisioning. No persistent admin accounts. MFA and session recording for privileged access. Extend the discipline to service accounts and machine identities, which are frequently over-privileged.
Where Cutover stands. Identity is not our lane. But the last sentence is aimed squarely at the agentic future, and Pat Opet's RSAC framing was that agents should run with "an identity but no entitlements." That is exactly the model an orchestration layer makes practical: the agent acts through a governed task, with an approval gate where the risk warrants it, and every action lands in the same record as the human work around it.
Cutover’s own posture
We operate on the principle of least privilege, meaning our employees are given only the minimum access rights to systems they need to carry out their jobs. If elevated access is required, it is granted through an audited approval workflow, and only granted for the minimum amount of time necessary to get the job done. These credentials are ephemeral and destroyed after the time window.
9. Manage remote access and segment where possible
What JPMorganChase asks. Strong multi-factor access with verified devices. Segmentation between trust levels. Authenticate and authorise every connection. Design so compromise in one environment cannot cascade. Red team regularly.
Where Cutover stands. Not our lane, with one relevant property. Because Cutover sits outside the customer network, recovery teams can reach their runbooks and coordinate when internal collaboration tooling is itself inside the blast radius. Several banks cite this as a reason the platform is part of their cyber recovery design rather than just their DR design.
Cutover’s own posture
All user authentication is routed through enterprise Identity Providers (IdP) enforcing mandatory Multi-Factor Authentication (MFA). Access to our cloud environment is restricted to authorized corporate devices using an encrypted secure access service to validate that connections originate solely from secure, MDM-protected endpoints. Integrated identity and entitlement management enforces fine-grained access based on the principle of least privilege, requiring explicit justification and approval for all temporary Just-In-Time (JIT) access requests.
Logical segmentation across dedicated datastores, isolated VPCs, and container namespaces enforces strict tenant containment, ensuring any security incident is strictly localized and architecturally barred from pivoting into adjoining environments.
10. Embed security into the AI development and deployment lifecycle
What JPMorganChase asks. Threat model AI systems early. Treat models, training data and inference pipelines as high-value assets. Validate that AI-generated code meets the same review and testing standards as human-authored work. Govern and red-team AI systems. Invest in AI-augmented defence to match adversary pace.
The execution problem inside it. Patchmageddon is blunt: autonomous agents can be part of the problem. It records an OpenAI agent escaping its sandbox during testing and breaking into a third party's production infrastructure. The paper also notes that the length of task an AI can complete independently is now doubling every three to four months. Agents will be doing more. The question is where.
How Cutover responds. Our answer is that the actor should not change the governance. Whether a task is executed by a human, an automation or an agent, it runs inside the same runbook with the same sequence, the same approval gates and the same timestamped record. External agents plug into a task over AG-UI, or act on the runbook through MCP. AI-generated changes are held to the same standard as human ones because the standard is the runbook, not the author.
Every incident then becomes labelled execution data: what was done, in what order, by whom, with what outcome. That is the training signal for the next generation of agents, and it is data that does not exist in logs or tickets.
Cutover’s own posture
Cutover embeds AI security across every phase of development and deployment through automated, continuous testing and strict architectural isolation. Managed as code and deployed via automated CI/CD pipelines, our AI service incorporates automated evaluation harnesses and strict output schema validation directly into build gates to screen every prompt and logic update for vulnerabilities, prompt injection, and output quality prior to release. Underpinning this is a NIST AI RMF-aligned governance framework backed by regular threat modeling, architectural decision reviews, and real-time operational monitoring.
In production, Cutover operates on a non-autonomous, human-in-the-loop paradigm where AI agents function strictly within standard user role-based permissions (RBAC). System interactions run through isolated containerized clusters and enterprise cloud foundation models, enforcing localized regional data residency and envelope encryption. Customer payloads are processed purely in-memory and immediately discarded - guaranteeing zero data retention, zero cross-tenant comingling, and no model fine-tuning on customer data.
Ultimately, governance remains author-agnostic: whether a task is executed by a human, an automated script, or an AI agent, it runs inside the same runbook, subject to the same approval gates and immutable audit logs. Operational telemetry is decoupled from customer payloads, capturing structured execution metadata that provides a transparent, tamper-proof audit trail while continually informing platform resilience.
What we are not claiming
Cutover is not a scanner, a CMDB, a PAM system or a firewall.
Detection, inventory, identity and network controls belong to specialists who have spent decades on them, and the ten actions rightly lean on all of them.
What we do is the layer between knowing and done. Three of the ten actions are execution problems wearing security clothing.
Four more depend on execution to have any effect. That is where orchestration earns its place in an AI-ready cyber resilience architecture.
Start with the three that are execution problems
If you are working through the ten actions, start with four, six and ten. They are the ones where a plan on paper and a plan that runs produce completely different outcomes. They are also the ones you can measure in weeks.
See how orchestrated execution works against your own runbooks: cutover.com/book-a-demo
The scorecard
Frequently asked questions
What are JPMorganChase’s 10 actions for AI-ready cyber resilience?
Published April 2026 by JPMorganChase’s Global Technology Leadership Team: (1) run the latest software versions, (2) manage assets and components with reference data, (3) build a vulnerability management programme, (4) stress test incident response and resiliency plans, (5) know your SaaS and outsourced dependencies, (6) optimise change management for speed, (7) filter outbound traffic, (8) remove standing privileges, (9) manage remote access and segment, (10) embed security into the AI lifecycle.
Which of the 10 actions does Cutover address directly?
Actions 4, 6 and 10 are core capability. Cutover supports 1, 2, 3 and 5. Actions 7, 8 and 9 are network, identity and access controls.
Is Cutover a vulnerability scanner, CMDB, PAM tool or firewall?
No. Cutover is the orchestration layer between knowing and done. It binds runbooks to CMDB data, measures remediation velocity from the execution record, and governs human, automated and AI-agent tasks in one runbook.
How does orchestration help with stress testing incident response (action 4)?
The exercise and the live response run through the same runbooks, so the rehearsal is the response. Findings become owned tasks. One multinational bank cut recovery testing time from 12 weeks to two across 5,000 services.
How does Cutover govern AI agents (action 10)?
Human, automation or agent, every task runs in the same runbook with the same sequence, approval gates and timestamped record. External agents connect over AG-UI or MCP.
Is Cutover itself one of the dependencies in action 5?
Yes. Cutover runs as SaaS outside the customer’s network, which is why banks use it in cyber recovery when internal systems are compromised, and it is itself a dependency to assess.