IT Cost Optimization for Banks: Run-vs-Change and the Tools Nobody Uses

Key takeaways

‍

• Run-versus-change splits IT spend into keeping existing systems working and funding new projects. Most banks lean toward “run” since it’s a safer bet.

• IT cost leaks in specific, predictable places: licensed but unused software, overlapping tools doing the same job, seats nobody uses anymore, and unnecessary premium tiers.

• A critical platform and an expensive-yet-useless one can be indistinguishable with license data alone, since a contract register only shows what was bought and says nothing about what gets opened day to day.

• Usage data give IT a control baseline to make run or change decisions from. Another round of budget cuts without a baseline to measure against can’t objectively tell if those budget cuts are valid.

‍

‍

Ask a bank's IT finance team what they're spending on, and the contract register gives a clean answer: licenses, seats, tiers, all itemized and accounted for. Ask what's actually being used, and the room goes quiet.

‍

IT cost optimization programs should aim to make that question answerable. A straight cut-or-keep of the most conspicuous line items without context of how those licenses are used inevitably ends up cutting useful programs or keeping wasteful ones.

‍

A contract register shows what you’re paying for. Usage data shows behavior. The closer these layers align, the smarter decisions you can make about what  to run or change.

‍

What IT cost optimization means

‍

IT cost optimization is the ongoing practice of aligning IT spend with what the business needs, by eliminating waste and shifting budget from maintaining existing systems toward funding new ones. It's a continuous discipline that depends on knowing what gets used as well as what was bought.

‍

IT cost reduction is often used interchangeably, but implies a single event instead of an ongoing discipline. Most IT cost reduction strategies aim at a blunt budget cut. A flat percentage reduction treats a critical platform the same as an unused one, usually cutting whatever's easiest to justify rather than what’s prudent.

‍

Real optimization requires knowing which tools earn their cost and which don't, then acting on that difference instead of applying the same cut everywhere. Without that distinction, a cost program is just guesswork with a spreadsheet attached.

‍

For a bank carrying years of accumulated systems, precision matters more than the size of the cut itself. A smaller reduction applied correctly against the tools nobody uses outperforms a larger cut applied blindly across everything.

‍

Run versus change, explained

‍

Run vs change is the split between two very different uses of the same IT budget.

Run-the-bank (RTB) covers what it costs to keep existing systems operating: licenses, infrastructure, support, maintenance.

Change-the-bank (CTB) covers new projects, transformation initiatives, and anything meant to move the bank forward rather than just keep it standing still.

‍

Most banks lean heavily toward run. McKinsey’s Q4 2024 analysis of bank technology spending found that run-the-bank and mandatory-change spending together often reach 70 percent of the technology budget, leaving limited room for anything discretionary. That ratio tends to build up gradually, one system and renewal at a time.

‍

A high run share in your own budget isn't automatically a problem. Some of it reflects a legitimately large, mission-critical system estate that has to keep operating as-is regardless of what else is happening.

‍

But a run share that high usually signals budget trapped in rigid legacy upkeep rather than flexibility for anything new and potentially enabling. It's worth asking specifically why the number sits where it does, before assuming it's the cost of doing business at that scale.

‍

Shifting that ratio doesn't mean cutting run spend indiscriminately, and it isn't a one-time exercise either. It means finding the specific parts of the run budget that aren't earning their keep and freeing that portion for change, without touching the systems the bank depends on to operate day to day.

‍

Doing that requires knowing which systems fall into which category, which most run-versus-change conversations gloss over or skip.

‍

Where IT cost actually leaks

‍

IT cost leaks in a small number of predictable places, which rarely show up on a contract register:

‍

Licensed but unused software. A tool gets purchased for a project or a pilot. The initial push fades, and the license keeps renewing at full price despite rare use.

‍

Overlapping tools doing the same job. Two teams solve the same problem independently, each on its own contract. The redundancy remains invisible because the tools live under different budget lines and different vendor relationships.

‍

Seats provisioned for people who have left. An employee moves on. The license stays active because deprovisioning isn't tied to anything that automatically flags it for review.

Premium tiers where the premium features are never opened. A team upgrades for one specific capability, uses it briefly, and keeps paying for the higher tier long after that capability has outlived its usefulness. Nobody downgrades back, since they assume the upgrade was done with good reason.

‍

Shadow tooling bought outside procurement. A team pays for a tool directly, on a card, without it ever entering the formal register, or does a free trial that rolls into a license. This kind of shadow IT spend belongs more squarely to procurement rather than run-versus-change.

‍

Every one of these leaks shares the same trait: the paperwork behind it is invisible to a normal register. Finding them requires usage data that captures activity and interaction to give a full and accurate picture of the run-vs-change landscape.

‍

Why license counts are not usage

‍

A contract register is good at what it does. It records the license count, the tier, the renewal date, and the invoice amount for every tool on the books. None of that tells anyone whether the seat is being used, or by how many people, or how often.

‍

License data answers "what did we buy." Usage data answers "was it worth it." The former is easy to answer, the latter isn’t. It should be obvious that both questions need concrete answers, but since the former is more convenient, most reviews stop there. Tables and totals of license data look sufficient enough to justify a decision.

Most cost reviews only have access to the first kind of data. A finance team can pull every contract, every seat count, and every renewal date without ever seeing whether those seats get opened. The half of the picture that digs deep to find waste is never even entertained.

‍

Usage data distinguishes mere input and spend from behavior that links to business outcomes. 

‍

An IT cost optimization framework

‍

Most IT cost optimization strategies fail the same way: they skip the usage step and rely on a spreadsheet to defend cuts. An IT cost optimization framework that follows a consistent sequence of measurement is a more defensible plan that leads to ROI.

‍

1. Baseline the current run and change split
2. Map the tool estate against actual usage
3. Band applications by usage depth
4. Act: retire, downgrade, consolidate, or renegotiate
5. Re-baseline

‍

Baseline the current run and change split. Establish exactly what percentage of your current IT budget goes to run versus change today, before proposing to move that number anywhere. Without a real starting figure, there's no way to know later whether anything shifted, or whether the ratio just moved on its own as budgets renewed.

‍

Map the tool estate against actual usage. List every application and license across your organization, then overlay how often each one gets opened, by whom, and at what depth of use. 

‍

This is the step most cost reviews skip entirely, since the license list alone already feels like a complete picture. The sequencing is not a matter of preference: ISO/IEC 19770-1, the international standard for IT asset management, places Trustworthy Data as the first of its three implementation tiers, ahead of life cycle integration and optimization. 

‍

Reliable data on what exists and what gets used comes before any attempt to optimize it, and pulling real usage data takes more effort than most quarterly reviews budget for.

‍

Band applications by usage depth. Group tools into rough tiers like heavily used, lightly used, and unused, so patterns become visible across the whole estate instead of one contract examined in isolation. A single unused license looks like a minor oversight. A whole tier of them looks like something worth acting on.

‍

Act: retire, downgrade, consolidate, or renegotiate. Each band suggests a different move. Unused tools get retired outright. Lightly used premium tiers get downgraded to a lower plan. Overlapping tools bought by different teams get consolidated into fewer contracts, freeing budget that had nowhere specific to go before.

‍

Re-baseline. The first baseline is a control to treat against. Measure the run and change split again once the changes take effect, so the next round starts from what's true now instead of what was true before the last pass. Usage patterns shift once people adjust to whatever changed. 

‍

What to do in the first three weeks

‍

Not everything in the framework above happens on the same timeline. Some of it you can start this week. Some of it needs a full quarter.

‍

What's measurable immediately: pulling the current license and contract register, since that data already exists and just needs to be assembled in one place. 

‍

Alongside it, you can typically get usage data for at least the applications your IT team already has visibility into. That's often enough to spot the most obvious unused licenses and overlapping tools within the first few weeks.

‍

What needs a full quarter: acting on what the data shows. Retiring a license, downgrading a tier, or consolidating two overlapping tools usually involves a notice period, a contract term, or a team that needs time to transition off a tool they've built habits around. Renegotiating anything meaningful also depends on where a contract sits in its renewal cycle.

‍

The mistake to avoid in the first three weeks is trying to act before the picture is complete. A quick win on one visible license doesn't tell you anything about the rest of the estate. Acting too early on partial data is how a well-intentioned cost review ends up cutting the wrong thing, while the real waste renews right on schedule.

‍

Where the usage data comes from

‍

Every step in the framework above depends on having usage data at all, and for most banks, that data doesn't exist anywhere the IT finance team can currently see it.

‍

Insightful’s Workspace Security delivers application and software usage data: which tools are actually used versus licensed, at what depth, and by which teams. That supports run-versus-change decisions and license retirement with evidence instead of a survey.

‍

It doesn’t replace a finance team's own review process. What it supplies is the piece a contract register can't produce on its own: which applications are being opened, and by how many people, across the organization.

‍

Mapping your IT portfolio against usage, banding applications by depth, and deciding what to retire or renegotiate all depend on trustworthy activity and interaction data. Otherwise it gets reconstructed from memory, or a survey someone filled out under time pressure.

‍

Measuring software tool usage and cost this way is what turns a license count into something that can justify an IT cost decision with objective clarity.

‍

The evidence, not the estimate

‍

License counts tell you what was bought. Usage data tells you what was used, with evidence. Connecting the two surfaces the savings and business results your company is after.

‍

A run-versus-change ratio that only gets challenged by a contract review will keep shifting slowly, if at all, and will continue to lag behind behind the real work being done. 

‍

Book a demo to see which applications are earning their cost.

‍

Frequently asked questions

What is the run vs change IT cost ratio?

The run vs change IT cost ratio splits IT spend into two categories: running existing systems and funding new projects or transformation. McKinsey put run and mandatory change together at up to 70 percent of the technology budget at large disclosing banks in 2024. A high run share signals budget trapped in legacy upkeep rather than available for anything new.

‍

What is IT cost optimization?

IT cost optimization is the ongoing practice of aligning IT spend with what a business needs, by eliminating waste and shifting budget from maintaining existing systems toward funding new ones. It's a continuous discipline rather than a single budget event, and it depends on usage data as well as a license count.

How do you reduce IT costs without cutting capability?

Reducing IT costs without cutting capability means targeting waste while leaving the systems people depend on alone. That starts with usage data showing which tools are barely opened, then retiring, downgrading, or consolidating those specifically, while leaving the platforms teams rely on untouched. A blanket percentage cut can't make that distinction.

What percentage of IT budget should go to run versus change?

There's no single right percentage. McKinsey's 2024 analysis put run and mandatory change together at up to 70 percent of the budget at large disclosing banks. The right target varies by organization, depending on how large and complex the existing system estate is. What matters more than hitting a specific number is knowing why the current ratio sits where it does.

How do you find unused software licenses?

Finding unused software licenses requires usage data. A contract list alone will not show it. Start by mapping every license against how often it's opened, by whom, and at what depth. A license with little or no activity over a full measurement cycle is a strong candidate for retirement, regardless of what the contract register alone suggests.

‍

‍