Of the many difficulties I face when trying to quantify risk, lack of a consistent nomenclature is one of the more significant. Currently, we can’t even agree in which units we should denominate the discussion.

To make matters worse, we’re expected to measure our estimates in different units depending on the audience. While this is implicitly an indicator of the audience’s agenda, it doesn’t change the fact that we need to know what that agenda is, then translate all of our arguments accordingly.

Management likes Dollar Value. Their concern is the impact this is going to have on the financial performance of (their project|their department|the company|their compensation).

IT Operations staff want to hear it in terms of outage length or staff hours required to support the mitigation strategy. They, in turn will run it through their own equations to turn the cost into dollars for their management.

Regulators and auditors want to talk about risk in terms of the effectiveness of the solution and in terms of preventative or detective controls. They could care less about cost.

The public and the press want to hear about risk in terms of lives lost and impacted. The bigger the numbers, the better. Which makes it strange that they haven’t picked up on Avian Flu more strongly than they have. I guess that “bigger is better” only goes so far.

The people left in the middle questing for some sort of Risk Rosetta Stone are people like me.

To make matters worse, risk means something different to everyone. This is more than just the demand for different denominations for different audiences. To most of the non-security/risk people I talk to, risk is “Project Risk.” That is to say, “What are the odds that this will affect my project timeline or resource estimations?” This is because their success or failure is generally determined by how close to on-time and on-budget they complete their project. Whether it puts the company’s information at risk is Somebody Else’s Problem.

In their minds, Risk Avoidance is ignoring what I have to say because once they know about the Information Security risks, they might have to alter their project plan which could turn their project from “Green” to the dreaded “Yellow” on the stoplight report/dashboard which is all that senior managment ever sees.

I’ve found that unless I get my concerns addressed before the project timeline and budget are set, they probably never will be. And even when they are included in the project’s requirements, I have to make sure they don’t get cut to keep the project Green on the dashboard. But it’s better than nothing.

Now in closing, I want all the Project Risk people to repeat after me, “Ignoring the Risk is equivilent to Accepting the Risk, not Avoiding the Risk!”

Not that it’ll help, since they are compensated based solely on how well they manage Project Risk, but it’s worth a shot.