I recently participated in a CIO round-table to discuss mechanisms in which management teams assess information technology risks. Almost all of the CIOs said they were performing regular risk assessments, but they also expressed a lot of concern that the assessments were performed consistently or with high quality. The major concern between the CIOs was that they didn’t have a realistic view of their organization. (Garbage In = Garbage Out)

Risk Assessment, Light

The most popular assessment mechanism consisted of  sending small teams out to another facility for a peer review, networking, and information sharing. The assessment itself usually consists of management interviews and a day or two of on site observations of processes.  (fyi – Pen Tesing is not a Risk Assessment)

Overall, there is a lot of value from peer review when it comes to learning, knowledge transfer, and networking, but if you want a true risk assessment this method falls short. The biggest problem is that peer-assessors rarely have a holistic perspective – that is – the don’t necessarily understand the cumulative impact of assessment finding. It’s very easy, and even logical, from the perspective of a peer-assessor sweep any one finding under the rug and it goes unreported. Why get your colleague “in trouble” for a misconfigured firewall?

The missed opportunity is examining the collective effect of this finding. For example, one of the most common issues I find is that companies fail to remove terminated employees from system access. For any one department 1-2 leftover users isn’t a big deal, but when you zoom out there could be hundreds of issues across the organization. At the department level it doesn’t seem like a big deal, but as an organization it becomes opportunity for user take-over and evidence that there is a process breakdown somewhere.

Better Risk Assessment

To perform a better risk assessment there should be a dedicated team to track, and ideally, perform risk assessments across the organization. This helps ensure a minimum and agreed upon risk assessment process as well as mechanism to analyze and categorize risks over time. (I wrote about examples of that here and here.) That role is often filled by internal audit (if they have the technical skills), a dedicated security team under IT, or external consultants.

Here are some tips:

  1. Create Independence – The team shouldn’t feel like they are betraying the team if they report an issue. Similarly, they shouldn’t feel like they will get a leg up by being too harsh.
  2. Involve Experts – While you want independence you also want experts. Assemble a team that is an expert in risk. If you choose to use external consultants it may also be helpful to assign an in-house project expert who understands the nuances of your environment.
  3. Implement a Tracking Mechanisms – Track results over time to develop trends and patterns. This will give you an idea of your company’s riskiest areas, help select projects and dedicate resources, and track improvement over time.
  4. Periodically Update the Risk Assessment Plan – Things change with new information and processes. Choose projects and update the risk assessment at least annually.
  5. Use Data to Drive Decisions – that includes application inventory/risk, vendor inventory/risk, analysis of spend, geographical risk, and alignment to business drivers.