How to Justify Cybersecurity Investment to the Board

If you work in IT or security, you have probably lived through this: you know there is a real risk, you know what needs to be done, but when you present it to the board, the budget does not get approved.

The problem is almost never the money. It is how the argument lands.

Directors and CEOs do not think in terms of vulnerabilities, CVEs, or the OWASP Top 10. They think about business risk, operational continuity, legal liability, and reputation. If you present the problem in the wrong language, it will not seem urgent — even when it is.

The most common mistake

Most IT presentations to the board follow a similar pattern: a list of vulnerabilities found, a technical classification, a proposed solution, and the cost of the investment.

The problem is that without business context, a list of vulnerabilities means nothing to the people on the other side of the table. "We have an authentication flaw in the admin panel" does not provoke the same reaction as "anyone with internet access can get into the panel and export the customer database".

The two sentences describe the same thing. But one of them creates urgency and the other does not.

Translate technical risk into business risk

This is the central point. For every vulnerability or security gap you want to address, ask: what happens to the company if this gets exploited?

The answers usually fall into a few categories that executives understand well:

Direct financial impact. Incident response costs, legal fees, notifying affected customers, regulatory fines. IBM's Cost of a Data Breach report puts the average cost of a breach in Brazil at around R$ 6 million (BRL). That number carries weight in a budget conversation.

Fines and legal liability. The LGPD (Lei Geral de Proteção de Dados, Brazil's General Data Protection Law) provides for fines of up to 2% of revenue, capped at R$ 50 million per violation. But beyond the financial penalty, the ANPD can suspend data processing — which, depending on the business, means ceasing to operate. That is an argument that needs no translation.

Operational continuity. How much does one hour of system downtime cost your company? Multiply it by 72, the average downtime in ransomware attacks. The resulting figure is usually far larger than the security investment you are asking for.

Reputation and contracts. Enterprise customers are increasingly demanding evidence of security maturity as part of their vendor approval process. Losing a contract because you failed a security audit is a concrete cost that the board understands.

Compare the cost of the control with the cost of the risk

A direct way to structure the argument is to put both sides in the same equation. On one side, the cost of the investment you are proposing. On the other, the expected cost of the incident that investment prevents — multiplied by the probability of it happening.

It does not need to be an academic analysis. Even a conservative estimate works. If a pentest costs X and a security incident would cost 20X, the conversation changes.

What the board needs to see is that you are not asking for money to solve an abstract technical problem. You are asking to reduce a concrete financial risk.

Use real examples from similar companies

Public incident cases at companies in the same industry or of the same size are powerful tools. Not to scare people, but to show that the risk is not hypothetical.

In Brazil, recent years have seen breaches at companies of every size — some with impact public enough that any executive will have read about it. Using those cases as a reference contextualizes the problem in a way abstract data cannot.

Present a proposal, not a problem

Executives would rather approve solutions than hear about problems. When you bring only the diagnosis to the meeting, you put the burden of deciding what to do on their side of the table — and the default answer is to postpone.

Arrive with a structured proposal: what will be done, for how much, in how long, and which risk it addresses. The easier it is to say yes, the higher the chance of approval.

If possible, also show what is not covered — that is, the residual risk that remains even after the investment is approved. This demonstrates maturity in the analysis and avoids the expectation that security is a problem you solve once and for all.

One last thing

Security will never compete on equal footing with projects that generate new revenue. That is not how budgets work at any company.

But when the argument is well constructed — real risk, concrete cost, clear proposal — it stops competing with growth projects and starts competing with the cost of the risk itself. That is a different conversation, and it is one you have a much better chance of winning.