Requests for security investment fail in a predictable way. Engineering describes risk qualitatively, leadership hears a preference competing against customer features, and the features win. The problem is not that leadership is careless; it is that one side is describing a possibility and the other is allocating money, and possibilities do not compete well against roadmap items. The fix is to model one specific incident properly.
Pick a plausible scenario rather than the worst imaginable one. For most Indian software businesses that is a compromised credential leading to unauthorised access to customer data — not a sophisticated nation-state attack. Being concrete matters: a named system, a named category of data, a realistic number of affected records. A scenario nobody can picture produces a number nobody believes.
Then count the components, in order of certainty. Investigation and forensics, which for anything serious means external specialists. Legal advice. Regulatory notification, which under CERT-In's six-hour rule and any sectoral obligation is a compressed and expensive exercise. Customer notification and the support volume that follows. Remediation engineering. Business interruption while systems are down or degraded. And, where applicable, contractual liability to enterprise customers whose agreements specify it.
Add the commercial consequences, which are larger and harder to state. Deals in progress that stall while your security posture is reassessed. Enterprise customers exercising audit rights. Renewal conversations that become negotiations. Churn among customers who were already marginal. These are the costs that dominate the total and the ones most often omitted, because they are uncomfortable and imprecise — but a range is far more useful than silence.
Then compare against the specific control you are proposing. This is where the exercise earns its keep: phishing-resistant multi-factor authentication across administrative access, or removing standing production access, or a secrets manager, costs a nameable amount and measurably reduces the likelihood of exactly the scenario you modelled. That is a comparable pair of numbers, and it converts an argument about diligence into an ordinary investment decision.
One caution about how the model is used. The point is not to produce a frightening figure — inflated numbers get discounted and the credibility is spent. It is to produce a defensible one, with the assumptions written down, that survives a finance director asking where each component came from. Security programmes funded on the back of a credible model keep their funding the following year. Programmes funded on alarm do not.
