I've seen scenarios in which organizations don't invest enough in cybersecurity, are short-handed, and thus have a difficult time meeting the policy requirements defined within their Security Programs. I would assume that many companies don't properly invest in cybersecurity and that this scenario is fairly common.

My question is related to measuring risk of not meeting policy requirements. Measuring risk by performing a standard risk assessment is well defined: identify threats/vulnerabilities and assess the impact and likelihood of exploitation. But what about the situation where you don't know the likelihood/impact of vulnerabilities because you literally just don't have the manpower to perform a risk assessment across all of your systems?

In basic terms: how can you assess and properly communicate the risk associated with not following policy? For example, the risk associated with not performing risk assessments across each of your systems?

Any ideas? I find that communicating risk up the chain of command is the best way to get resources to tackle problems. Am I framing this incorrectly by thinking about it in terms of risk?

  • Risk management is a broad topic, and proves complex to so many businesses they hire other companies who deal exclusively with risk management. You probably have insurance for something in your life which you probably shopped around for. The 4 ways to manage risk are acceptance, avoidance, transference, and mitigation. The way you assess risks can be done through a qualitative or quantitative assessment (or both). Other topics include annual rate of occurrence, and annual rate of impact. Commented Jun 13, 2020 at 8:30

2 Answers 2


You are not using a useful risk assessment process, which is why you are having trouble coming up with a measure.

Importance of Inherent Risk

You are combining likelihood and impact with the mitigations (people, controls, policies, etc.). A risk assessment first assesses the risk without mitigations. This gives you your inherent risk. Sometimes you can assume some mitigations in inherent or a constant, so you can use that knowledge in your assessing of inherent risk. But, as you say, you can't assume that you have everything you need to mitigate.

Residual Risk

Your mitigations (people, controls, policies, etc.) reduce that risk level to a new level (hopefully a lower one), called residual risk.

Your assessment process needs to consider the impact of the mitigations carefully so as not to assume that those mitigations are always there.

Policies as Risk Mitigation

Policies are one of those mitigations. You should carefully consider the impact a policy has, or else you have a useless policy (or you copy/pasted it from some source online or an external expert who had ideas one day). So, you should already know the impact of not following a policy.

Risk Communication

You are correct that having the right information is the best thing you can do to improve your security posture and communicating to decision-makers. You need to communicate the gap between:

  • inherent risk
  • your current residual risk
  • your target level of residual risk (a step most people forget about, because, no, you can't and shouldn't get all risks to "green" on a heatmap)

Specific Example

If you do not perform risk assessments on systems, then you have no means of effectively controlling the potential impacts on those systems (the risk assessment is a form of mitigation from the org perspective). So, then, you potentially have no controls against impacts, which means your inherent risks are considered to be your actual risks. Risk assessments on the systems help define how to lower your risks (impacts/likelihoods).

  • Thanks for the slow and methodical explanation, that's great. The issue is that many controls do exist that mitigate risk, but the work required to identify the controls that have been implemented and the corresponding residual risk has not been completed and isn't properly resourced within the organization. Speculating that the inherent risk is the actual risk just isn't correct, and management knows this. I'd like to figure out the best way to communicate to management the risk associated with not identifying the residual risk of the systems. Commented Jun 12, 2020 at 2:40
  • Then I'm confused. First, that's not what you asked in the question. Second, what I've said addresses this directly. If you don't know what your residual risk is, then you must assume that the inherent risk is the residual risk until you know differently. The only way to manage the risk is to assess. "But stakeholders know some controls are in place." That's nice. But without an assessment, the impact of the controls is purely speculative or imaginative. "We have a fire extinguisher, therefore the building can't burn down, right?"
    – schroeder
    Commented Jun 12, 2020 at 7:21
  • If that is your question, then I think your question is no longer about risk, or even security. You have a question more suited to workplace.stackexchange.com Managing and assessing risk is a core function of business leadership. They know what to do at the most basic level. So, either, your business leaders know nothing about basic management, or you don't know how to tap into the processes they use to manage other business issues and apply that to security. If either is the case, then this ceases to be a security question.
    – schroeder
    Commented Jun 12, 2020 at 7:22
  • 1
    Again, this is an entirely different situation than what you have previously described, but is also answered above. Replace "stuff" with "process" above. What you have is a control with, what you speculate to be, an impact that might be lower than expected. The control is suspect by the fact that you have identified a weakness. You now have no idea what impact it is actually having. You have an unknown residual risk. That's what you need to communicate. My answer still addresses all of this.
    – schroeder
    Commented Jun 12, 2020 at 23:41
  • 1
    No one would accept a situation where all the smoke detectors are not tested, but when sampled, a few of the sample are found to be faulty. Any reasonable person would test all the smoke detectors. "Your assessment process needs to consider the impact of the mitigations carefully so as not to assume that those mitigations are always there."
    – schroeder
    Commented Jun 12, 2020 at 23:43

Although a little late to the party, here are my 2 cents (para-phrasing some parts of @schroeder's answer / comments above, with some secret sauce of my own.

  1. Not following policy is NOT a risk. The risk is the reason why policy exists.

Taking your example of missing patches, you seem to be on the right path. Some additional things to do to qualify the risks:-

a - are those missing patches map to any CVE? If yes, are those CVE's exploitable? If yes, what is the impact (Remote code execution, server compromise, potential data leakage, etc.)? What are the pre-requisites for the exploit (pre-auth, post-auth, privilege escalation, etc.);

Your run-of-the-mill VA tool (e.g., nessus, nexpose, etc.) should give you data points on this.

b - how critical is the data (on the server with the missing patches)? if the server and data on it are not critical, are they connected to any machine which is (critical)?

c - What does your internal risk assessment methodology say about qualifying / quantifying the risk?

After you qualify / quantify the risk (it is always a scenario that is risky, never the vulnerability / threat / data), you can then state the absence of an existing control (policy) which is not followed (in this case), resulting in the risk scenario to be plausible.

Risk communication fails because the scenarios are not aligned with business, nor do they provide a context to it. e.g., unless a risk results in potential loss, business won't care.

And they would be right in doing so.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .