The Chain Reaction Nobody Wants Several years ago, I worked with a global asset manager undergoing a cloud migration. It sounded exciting. The cost savings and scalability benefits were all there. But what wasn’t on the slide deck was how many business-critical applications still depended on legacy architecture that wasn’t cloud-compatible. In one instance, a reporting tool that pulled position data for risk oversight failed to retrieve accurate feeds after the cloud switchover. The result? Inaccurate risk reports sent to internal committees and a scramble to recall and correct them before external eyes got involved.

What did we learn? The importance of technology change governance. Before any major tech overhaul, every upstream and downstream dependency needs to be mapped, tested, and retested. Simple rule: if it can break, it probably will—unless you’ve planned for it not to.

Cyber Risk: The Ever-Present Shadow No article on tech risk is complete without mentioning cybersecurity. And it isn’t just about firewalls and encryption. A breach can come from an innocuous email attachment. At another institution I advised, a phishing email compromised an employee’s credentials. No big deal, right? Wrong. The compromised ID had access to a dormant third-party file transfer protocol (FTP) server still linked to live customer data. That one oversight turned into a multi-month breach investigation.

We took action quickly: reviewed all privileged access, killed off dormant accounts, revamped endpoint monitoring, and launched mandatory cyber-awareness training. But we also rewrote our third-party risk policy to emphasize identity lifecycle management and data minimization.

Regulations and Frameworks: A Compass, Not a Crutch Regulators have taken note. The NYDFS Cybersecurity Regulation (23 NYCRR 500), GDPR, and FFIEC guidance all outline expectations for managing tech risk. Yet compliance with these laws shouldn’t be the ceiling—it should be the floor.

One client of mine adopted the NIST Cybersecurity Framework as a strategic blueprint. By pairing it with FAIR (Factor Analysis of Information Risk) modeling, we quantified risk exposure in dollar terms. This helped the board better understand why we needed a budget increase for endpoint detection and response. Dollars and metrics speak louder than fear.

The People Side of Technology Risk Technology risk is never just about the tech. People build, maintain, and use systems. And people are fallible.

At a mid-sized bank, a developer wrote a script that bypassed a manual review step to speed up processing. It worked. Until one day, it didn’t. The script ingested corrupted data, which went unchecked, leading to a cascade of reconciliation issues across six business lines. It took days to untangle.

This incident led to our “Human Factors in Technology Risk” initiative. We didn’t just audit the code. We started asking: Why did the developer feel the need to create a workaround? Was it a culture that celebrated speed over controls? Were teams empowered to report fragilities? These are cultural questions as much as operational ones.