Controlling expectations

If you’ve ever wanted to see a group of employees have their energy sapped, sit in on a risk assessment presentation that is technically accurate on the risks facing the project but overwhelmingly negative and damning. It’s also a great way to ensure you’ll never be invited to another project.

The reporting of risk requires some tact. Unlike an audit, risk assessments should theoretically advise the project team of key issues facing the successful completion of the initiative. But all too often, the risk assessment and subsequent report become an opportunity to “lay blame” on the project team for failing to address critical security requirements.

I have been guilty of this in the past. I was involved in a few situations where the risk assessment highlighted some critical risks to the project. I took it upon myself to present the report, and then suffer an unending series of questions, comments and criticisms. “Where did you derive your conclusions from?” “We had a project plan; didn’t you review it?” “We talked about these issues. Why are they being included in this report?” Well, you can see where this ended. I had some significant rewrites to complete, and more work rebuilding relationships with senior management and the project team.

In past columns, I described the collaborative approach taken to develop a risk management framework, and the effort required to develop definitions of threat, risk, likelihood and impact. I mentioned these initiatives require input from diverse working groups, with business and operations meeting and eventually accepting common terms of reference. All of this good work can be lost, though, in the process of assessing risks and reporting findings to senior management.

A risk management program has to have a solid foundation of collaboration in both the process and the reporting to be successful. A risk program that doesn’t involve collaboration in the reporting process can thwart any positive work experienced from the process side. What begins as an exercise in team consensus and (eventually) camaraderie can unfortunately end up in disagreements and executive memos written to defend both sides of an assessment.

You can avoid a number of confrontations by scheduling regular project team meetings to provide ongoing updates regarding the risk assessment, and ensure you continue to take into account the business context of the project.

There must also be a process to document the acceptance of risk. Not every project has an unlimited budget or timeline. While that may seem hard to accept, we see that every day in our organizations. Our companies develop an initiative to address a market demand, a customer request or a legislative requirement and there are limited funds to address identified risks. In our efforts to secure our organizations, we have (in the past) identified expensive controls we consider “mandatory” to protect our assets.

In a collaborative risk assessment, your goal is to work with the project team to assess the risks facing the project, document what controls are in place to address risks, and highlight areas the organization should focus on that may not have adequate controls.

We must objectively report these risks to senior management, who decide what level of risk they are willing to accept, document this acceptance, and assign a review date to the document. Accepting risks is something all organizations do but there shouldn’t be an open-ended timeline for dealing with them. That’s a recipe for future breaches.
 
Tim McCreight is the chief information security officer for the Government of Alberta (www.alberta.ca).