Ransomware preparation is the security investment that organizations discover the quality of during the worst possible moment. The backup strategy that was designed but not tested reveals its gaps when the organization needs to restore from it. The incident response plan that was written but not rehearsed reveals its gaps when the team is trying to execute it under pressure. The cyber insurance policy that was procured but not fully read reveals its requirements when the claim is filed.

Corporate laptop procurement has not kept pace with the changes in how knowledge workers use their devices. The procurement criteria that dominated enterprise laptop purchasing for the past fifteen years — Windows compatibility, Intel processor, specific RAM and storage tiers, corporate image support — are still driving purchasing decisions in organizations where the actual requirements have shifted materially. The mismatch produces laptops that are enterprise-manageable but mediocre for the work employees actually do.

Endpoint Detection and Response platforms replaced antivirus as the dominant endpoint security technology on the basis that signature-based detection could not keep pace with the volume and variety of modern malware. The replacement was justified. EDR’s behavioral detection, continuous telemetry, and forensic capability represent a genuine improvement over signature-based antivirus in detecting and investigating endpoint threats.

The marketing that followed — the promise of comprehensive endpoint security that would significantly reduce breach frequency and impact — overstated what the technology can deliver. EDR is better than what it replaced. It is not the endpoint security solution. Endpoints continue to be compromised at scale in organizations running mature EDR deployments because the threats that matter most have adapted to operate within the behavioral envelope that EDR considers legitimate.

The self-service IT portal is one of enterprise IT’s most persistent good ideas with consistently poor implementation. The idea is sound: employees who can resolve their own IT issues without contacting the helpdesk reduce the support burden, resolve their issues faster, and build a level of IT self-sufficiency that benefits the organization. The implementation failure is that self-service portals are almost universally designed to make it easy for IT to publish content rather than easy for employees to find solutions to their problems.

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.