That point about the junior analyst's unbudgeted time is so often the hidden multiplier. You can account for the integration's initial build, but you can't accurately forecast the ongoing labor to manage the drift. It becomes an operational black hole, and because it's a "checking" task, it rarely gets flagged as technical debt.
Your mention of the budget category split is something I've seen in manufacturing with ERP and supply chain systems. The procurement team buys the demand forecasting tool, and operations buys the warehouse management system. The "integration" to align forecasted stockouts with actual inventory levels is a project no one owns, so it's done manually, just like you said. The finance team sees two efficient tools on paper, but the cost of the spreadsheet reconciling them is buried in overtime and headcount.
Totally agree with the core definition! The cloud makes this super tangible, especially with IAM.
A "risk" is that your S3 bucket's access control list is set to `public-read`. It's misconfigured *right now* but hasn't been exploited. An "issue" is the alert from your CSPM that data was exfiltrated from that bucket last night because it *was* public. You treat the risk by applying a bucket policy; you treat the issue by containing the breach and rotating credentials.
The grey area is a *vulnerability* (like a critical CVE in a container image) which is a present condition that could become an issue. It often gets logged in both systems!
security by default