How many risk statements do you need to describe the information security risks to Management? Probably just one.

“What are our risks?” or “What is the risk?” has been a common refrain heard across my career. I’ve responded to those questions, depending on where I was in my career, with copious lists of technical vulnerabilities, a hoard of risk statements and more detail that the person asking the question expected. I think I did this to show I had lots of detail to back my position, that this was a big deal, that there were lots of problems. This was all true and remains true to this day; but in retrospect this was not the right response.

I think it was the wrong response because of who was asking me; these weren’t auditors, they were senior executives. Senior Executives hire people like me (and hopefully you) to simplify complex problems into key actions and specific decisions. Consider the Chief Financial Officer (CFO): her job is to take the complexity of the balance sheets and say “we’re profitable” or “we’re not profitable”; whether the company is performing within the expected plan and ratios or not. The underlying details of how that is determined and what issues there may be to solve is the CFO’s responsibility to address; only the most important problems must be surfaced. The CFO is a complexity filter so that the business can focus on it’s core mission and only deal with that which is absolutely must while trusting the CFO to handle everything else. This assumes that the CFO has the necessary access and authority to do that job. The same applies for all “Chief” roles.

If I were to counsel younger me, I would have suggested I had only this one risk to speak to:

The business will be unable to achieve its business objectives due to a unauthorized access or changes to systems and information. This unauthorized access may cause loss of customers and associated revenue, disruption to business activity, and increased expenses. This unauthorized action is possible because of deficiencies in security controls.

Every problem in information security drives that risk. It’s a broad statement but that is intentional. The CEO wants to know where we are relative to that risk. You will need lots of information to support your determination of how close the organization is to that risk becoming a reality.

Younger me would then likely have asked, somewhat exasperated, “What about all the controls gaps and issues and vulnerabilities and… and… ? Who will I tell those to?” and he would show me this list and I would respond:

• The web server is not patched! - That’s a vulnerability and an issue, not a risk - it’s real, it’s happened
• We don’t have secure code development practices! That’s a control deficiency, not a risk. It will increase likelihood of the one risk occurring
• We have weak passwords! That’s an issue, not a risk. It will increase likelihood of the one risk occurring
• We’re not properly securing the cloud! That’s a whole bunch of issues, but still not a risk
• APT506 is attacking our sector with sophisticated techniques! That’s a threat actor and their Tools, Techniques and Procedures, but not a risk
• … and many others

EDIT: The above do contribute to risk, they are risky behaviour, but they are not the risk itself.

The quick test to know whether you’re dealing with risk or something else is whether the matter you’re describing has a potentiality to it, a cause and a consequence. Better said a risk description is “structured statement of risk usually containing four elements: sources, events, causes and consequences” per ISO 73. If it doesn’t fit that structure, it’s probably not a risk. If you are able to restate it as a risk, then, it most likely will just be a specialized or narrower version of the one risk. You could present these specialized risks but they will likely blur together for all but the most technical audience. Ultimately the treatment is similar: implement or fix a control; details that an executive generally doesn’t need to know. The only time you might want to discuss a specific issue with a senior executive is if it’s about an issue directly in their control or a funding matter. Generally you want to presenting issues to a dedicate committee or working group (but always with the right “zoom level” to quote my colleague Drew C.).

Everyone of those items in the list above needs treatment, everyone contributes to the single risk in some way. Our vast list of issues we know of is our job to deal with. We need to drive action against those issues. We need to go engage the specific stakeholders and technology owners directly. Reporting issues to management is the functional equivalent of reporting them to management; that should be the last resort after all reasonable actions have failed. If we must report some details then we should aggregate those issues into specific scenarios that are business relevant. For example, the business may be embarking on a digital transformation initiative and so a specific security scenario we would want to discuss is how several security issues will impede the achievement of the desired digitization outcomes.

Closing thought: I speculate that the reasons we tend to show all the issues, as a profession, is that: (1) we have clarity on when the risk is actually too much (a planned future draft note); and (2) we’re not confident we have the access and reach to solve the issues without making them visible at the highest level. Perhaps that’s second problem is the first thing we need to treat.