Every enterprise IT organization is running software it should have replaced years ago. The system is old enough that the vendor who originally built it may no longer exist. The employees who know how it works are approaching retirement or have already left. The documentation, if it ever existed, is incomplete or missing. The integration with everything else in the technology stack was built on assumptions that have since changed. The system runs critical business processes that the organization cannot operate without.

Phishing has been the leading initial access vector for enterprise breaches for over a decade. Security awareness training — the annual compliance exercise that organizations deploy to satisfy auditors and reduce cyber insurance premiums — has been the dominant organizational response for the same period. The training has not significantly reduced phishing click rates in most organizations. The reasons are structural, not motivational, and the solutions require technical controls rather than behavioral ones.

Every IT organization with a persistent ticket backlog treats the backlog as the problem and measures progress by reducing it. This is the wrong frame. A ticket backlog is the visible manifestation of a supply-demand imbalance in IT support capacity — the result of a problem, not the problem itself. Treating the backlog as the target produces solutions that attack the symptom: hiring more helpdesk staff, implementing triage automation to move tickets faster, setting SLA targets that create pressure to close tickets quickly. None of these address why the tickets were created in the first place.

The four-year PC refresh cycle that became standard in enterprise IT during the 2010s was a budget optimization made under specific conditions: hardware improvements were incremental, Windows 7 was stable, and the marginal productivity gain from newer hardware was not large enough to justify more frequent refresh. Those conditions no longer hold. The PC refresh cycle at many organizations has stretched to five, six, and in some cases seven years without a corresponding assessment of whether the extended cycle is actually saving money.

The security vendor community has done something impressive with the Zero Trust concept: it has taken a principled architectural framework that requires organizational discipline, policy definition, and sustained implementation effort, and repackaged it as a product category that can be purchased and deployed. The repackaging is commercially effective. It is also misleading in a way that causes organizations to believe they have implemented Zero Trust when they have purchased a tool.

The average organization with 500 to 1,000 employees is running between 100 and 200 SaaS applications. A fraction of those are managed by IT. The rest were procured by individual departments, teams, and employees using corporate credit cards, expense reports, and in some cases personal cards that get reimbursed. The finance team knows about the ones with purchase orders. The IT team knows about the ones that went through the security review queue. Nobody knows about all of them.

Enterprise software procurement moves at a pace that the software it is trying to purchase has long since left behind. The average procurement cycle for a mid-market enterprise software purchase — from initial vendor identification to signed contract — runs between four and nine months. The software category the procurement team is evaluating will have shipped multiple major releases during that period. The requirements documentation that anchored the evaluation will have drifted from what the business actually needs. The vendor selected may have been acquired.