Imagine sitting in a meeting with the CEO of your company.
You have spent the last two days reviewing a security issue, and you finally have your findings ready. You look at the CEO and say, ‘There is a serious issue with the authentication mechanism of our application. An attacker could potentially escalate their privileges and gain unauthorized access.’ The CEO listens carefully and nods. Then comes the question that matters most:
What does that mean for us, and what do you want me to do? This is where many security conversations go wrong.
Technical Risks to Non-Technical The security professional has identified the problem correctly. The technical assessment may be completely accurate. The vulnerability may genuinely be serious. But if the person responsible for making the business decision does not understand what the risk means to the organization, the assessment has not really achieved its purpose. This is one of the areas where Governance, Risk, and Compliance, or GRC, plays an important role.
The language problem
Cybersecurity has its own language. People working in security can spend an entire meeting talking about MFA, CVEs, privileged accounts, vulnerabilities, encryption, patches, attack vectors, and access controls without thinking twice about it. There is nothing wrong with that language. We need it. The problem starts when we assume that everyone else understands it in the same way.
A CFO does not necessarily need to know how an authentication token works. A business head does not need to understand the technical difference between two types of vulnerabilities. A CEO probably does not need to see the output of a vulnerability scanner.
What they do need to know is much simpler. What can go wrong? How likely is it? What would happen to the business if it did? How much will it take to fix? What decision do you need from me? That is the conversation GRC should help create. Start with the business, not the vulnerability; one of the biggest lessons I have learned from risk
Consider a simple example: Suppose an application has an authorization weakness that could allow one customer to access another customer’s account.
A technical explanation
The application does not adequately validate authorization tokens, creating a potential horizontal privilege escalation vulnerability. That may be perfectly correct.
But now try saying this to a business stakeholder: There is a possibility that one customer could access another customer’s account without having their password. If exploited, this could expose customer information and result in complaints, financial loss, and regulatory consequences.
The second explanation is much easier to understand. Notice that we have not lied, simplified the risk beyond recognition, or hidden the technical problem. We have simply explained why the technical problem matters.
That is the difference between reporting a risk and communicating a risk. Another useful approach is to explain what could actually happen.
Instead of showing a stakeholder a page full of vulnerability details, walk them through the sequence. An attacker finds the weakness. They exploit it. They gain access to information they should not have.
The organization discovers the incident. Now the company has to investigate, contain the issue, communicate with customers, possibly involve legal teams, and deal with the impact on its reputation. Suddenly, the risk is no longer just an IT problem. It has become a business problem. This is why a seemingly small technical weakness can sometimes have consequences far outside the technology team. A compromised account can become a privacy issue. A privacy issue can become a legal issue. A system outage can become a customer service issue. And a prolonged outage can eventually become a financial issue. The technology may be where the problem starts, but it is rarely where the consequences end. Don’t use fear as your communication strategy. There is another trap that security professionals can fall into: making everything sound catastrophic.
-If we don’t fix this immediately, hackers could get into our entire network. Maybe they could. But saying something like this without evidence usually creates fear rather than understanding.
Good GRC communication is not about frightening people into approving security projects. It is about giving them enough information to make a sensible decision.
For example,
-
Statement 1: This is a critical vulnerability and must be fixed immediately.
Compared with:
-
Statement 2: Thirty-eight externally accessible accounts currently do not have MFA.
If credentials for one of these accounts are compromised, an attacker could potentially gain access to sensitive information. We recommend enabling MFA for these accounts within 30 days.
The second statement feels less dramatic. But it is much more useful. It tells the stakeholder what exists, what could happen, why it matters, and what action is recommended. That is what makes a risk assessment useful. Don’t just bring problems to management.
I think this is one of the most important responsibilities of a GRC professional. If we identify a problem and simply hand it over to management, we have only completed half the job. Suppose an organization has an old application running on software that is no longer supported. We could tell management: The application is running on unsupported software and represents a significant security risk. And then stop. But what happens next? Management knows there is a problem but may not know what to do with it. A better conversation would be:
We have three possible approaches. We can upgrade the application, replace it, or continue using it temporarily while putting additional controls around it. The first option has a higher immediate cost, while the third option leaves some residual risk. Our recommendation is to upgrade it within six months.
Now management has a decision to make. That is much closer to actual risk management. The role of GRC is not always to make the decision for the business. It is to make sure the business understands the decision it is making. Numbers only help when they mean something. Security reports often contain a lot of numbers. CVSS scores. Number of vulnerabilities. Number of affected systems. Risk scores. Percentages. Incident counts. Numbers can be useful, but only if the person listening understands why they matter. Telling a senior executive that a vulnerability has a CVSS score of 9.8 may sound serious, but it does not necessarily tell them what they need to know.
Instead, we can say: Fourteen production servers are affected, including three servers supporting our customer-facing application. That number has context; similarly, instead of saying, “Remediation is complex.”
You could say:
The development team estimates that fixing this will require approximately 120 hours of work and will need to be planned into the next release.
Now the stakeholder can start thinking about resources, timelines, and priorities.
The executive may only need to know the potential business impact, urgency, cost, and available options. The risk has not changed. The audience has. That is why good communication is not simply about knowing cybersecurity. It is also about knowing your audience. Sometimes the best GRC professional in a meeting is the person who knows what not to explain.
There may be twenty pages of technical evidence behind a finding. The executive may only need three sentences. That does not mean the evidence is unimportant. It means it has been placed where it belongs.
Always finish with a clear action. A risk discussion should not end with: Management should take appropriate action.
It sounds formal, but it does not really tell anyone what to do.
GRC is more than compliance.
Sometimes GRC is viewed as the team that maintains policies, prepares audit evidence, updates risk registers, and checks whether controls exist. Those activities are important. But that is not the whole purpose of GRC. At its best, GRC helps an organization make better decisions when there is uncertainty. A security engineer might discover a vulnerability. An auditor might identify a control weakness. A compliance professional might identify a regulatory requirement that is not being met.
But someone still needs to explain what all of that means for the business. That is where GRC adds real value. It connects the technical world with the business world. And that connection requires something that cannot be found in a vulnerability scanner: the ability to communicate clearly with people who think differently from us.
From identifying risk to managing risk
For me, the real test of good GRC communication is not how complicated the risk report looks. It is what happens after the conversation. If a stakeholder walks away thinking, “I still don’t understand what this means,” then the communication has failed, regardless of how technically accurate the report was. But if they can say:
‘I understand what can happen. I understand how serious it is. I know what options we have, and I know what decision I need to make,’ then the conversation has done its job.
That is the difference between identifying a risk and actually managing one. Cybersecurity professionals are often very good at finding problems. GRC professionals need to be equally good at explaining why those problems matter.
Because ultimately, the purpose of risk communication is not to prove that we understand technology. It is to help someone else make a better decision because we can understand it.
