Your infrastructure is audited. Your endpoints are managed. Your network is monitored. And your application estate can still be carrying risk nobody has quantified.
Direct answer: Application-level risk in financial services goes undetected because the tools most estates already have infrastructure security, network monitoring, endpoint compliance and identity platforms were built to measure devices, networks and identities, not what software is installed, whether it is supported, and who owns it. Passing every audit built around those controls does not mean the application layer underneath has been measured at all.
Financial services IT teams are, by necessity, among the most disciplined in any sector. Infrastructure security, network segmentation, endpoint compliance and identity controls are mature, audited and continuously improved because the regulatory and reputational cost of getting them wrong is severe.
And yet, conversation after conversation with financial services IT, security and risk leaders surfaces the same admission: nobody has a confident, current answer to “what is actually running across our application estate, and how much of it is a problem.”
That gap is not a failure of discipline. It is a structural blind spot.
Infrastructure risk and endpoint risk are visible because the tools most organisations already run are built to see them. Vulnerability scanners see network exposure. Endpoint management platforms see device compliance. What almost nothing in a standard IT stack does well is answer, at estate scale: which applications are installed, which are still supported, which are duplicated across business units, and who actually owns each one.
That gap is application-level risk. It sits underneath the layers that are already well-monitored, which is exactly why it persists in estates that otherwise look and largely are well managed.
Four structural factors make this worse in financial services specifically:
Acquisition and merger activity. Every acquisition brings another application estate, often on a separate Microsoft tenant, with its own naming conventions, ownership records and packaging standards. Consolidation is planned. It rarely finishes on schedule.
Regulatory pace. New compliance requirements arrive faster than legacy applications can be retired or replaced, so estates accumulate software that was compliant when installed and is not being actively reassessed.
Legacy dependency. Core banking, trading and risk systems frequently depend on older application versions that cannot simply be upgraded without a wider change programme creating a category of software that is known to be aged but is deliberately left alone.
Vendor and third-party software sprawl. Outsourced functions, contractor tooling and third-party platform integrations each add applications to the estate that sit outside standard internal procurement and review cycles, often without a clear internal owner from day one.
None of this reflects poor governance. It reflects the operating reality of running technology in a sector that changes ownership structures, regulatory requirements and core systems more often than most.
Each of these is invisible to a standard CMDB query and largely invisible to a network or endpoint security tool. They only become visible when someone asks the application estate the right questions directly.
Consider a mid-sized financial services group formed through three acquisitions over six years. Each acquired business brought its own Microsoft tenant, its own application estate, and its own packaging conventions. Group IT consolidated identity and network security relatively quickly a visible, board-level priority with a clear deadline.
Consolidating the application estate had no equivalent deadline, so it didn’t happen on the same timeline. Three years later, a security review ahead of a regulatory audit finds four different PDF editing tools installed across the group, two of which are past vendor support; a trading-desk utility running on a version with a known, unpatched vulnerability, installed on business-critical devices with no named technical owner in any of the three original organisations; and a compliance reporting tool duplicated under two different package names, both counted separately for licensing purposes.
None of this was hidden through negligence. Every device is managed. Every network segment is monitored. The organisation’s infrastructure and identity audits have consistently passed. The application layer sat underneath all of it, un-inventoried at group level, for the entire three years.
Risk type | What it looks like | Consequence | First action |
Unsupported/outdated versions | Applications past vendor support, still functioning day to day | Unpatched vulnerabilities, audit findings | Full-estate support-status inventory |
Duplicate/orphaned software | Same application category installed under different packaging | Wasted licensing spend, inconsistent patching | Cross-tenant deduplication pass |
Undocumented ownership | No named business or technical owner | Slow security triage, slow audit response | Ownership assignment exercise |
Regulatory/operational/financial overlap | Any of the above intersecting with in-scope regulatory systems | Compounded, board-level risk | Prioritise overlap cases first |
The cost of application risk that stays hidden rarely announces itself as a single, dramatic event. It accumulates through a set of quieter, compounding costs that are easy to underestimate until they are added up.
Licensing waste is often the first cost anyone quantifies, because it is the easiest to measure: duplicate tools counted separately across tenants, seats paid for on applications nobody actively uses, and support contracts renewed automatically for software that could have been retired. On their own, these look like inefficiencies. Across a multi-tenant estate shaped by several acquisitions, they add up to a material, recurring spend with no corresponding business value.
The second cost is slower incident response. When an application has no named owner, a security or compliance question about it is this patched, is this still supported, who approved this has no obvious person to answer it. That delay is rarely visible in normal operations. It becomes visible exactly when it matters least: during an active incident, or under audit, when speed of response is itself being scrutinised.
The third, and most consequential, cost is reputational and regulatory. A finding that an in-scope, regulated application was running an unsupported version with a known vulnerability discovered by a regulator or auditor rather than internally carries a different weight than the same finding surfaced proactively. The gap between these two scenarios is not the underlying risk; it is entirely about who found it first, and how prepared the organisation was to respond.
None of these costs require a major incident to materialise. They accumulate quietly in estates that, by every other measure, are being run well.
Passing an audit typically demonstrates that documented controls exist and are being followed. It does not typically demonstrate that the underlying application inventory is complete, current and free of the three risk categories above. An estate can be fully compliant with its documented process and still contain material undocumented risk because the process was never designed to catch what it does not know exists.
Compliance and audits are also, by their nature, reactive: a point-in-time snapshot that confirms what was true on the day of testing, rather than a continuously and proactively managed view of the estate. Few organisations actively monitor and update their application inventory between audit cycles, so new unsupported versions, ownership gaps and duplication can accumulate quietly for months sometimes years before the next audit cycle brings them back into view.
This is the uncomfortable finding behind most first-pass application risk reviews in financial services: the risk was rarely hidden because anyone looked away from it. It was hidden because nothing in the existing toolchain was built to surface it.
Before any technology decision, a useful application risk view answers four questions, in order:
Getting a credible answer to question one is usually the hardest step, and the one most estates have never actually completed at full scale.
A defensible application risk position does not mean a zero-risk estate that is not realistic for any organisation of scale. It means being able to show, at any point, an accurate current inventory, a documented view of where the risk concentrates, and evidence of a prioritised, resourced plan to reduce it. That evidentiary position is what regulators, boards and auditors are actually looking for, and it is achievable without a disruptive, estate-wide rebuild.
Want an early look at the application risk framework outlined above, applied specifically to financial services? We are running a practical session for financial services IT, security and risk leaders in October covering exactly this including a five-step model for prioritising the estate. Register your interest here.
This article is part of a sector series examining where operational, regulatory and financial risk overlap across complex application estates.
