How to Ensure Your IT Risk Committee Speaks the Same Language

Jeff B. Copeland

Many large organizations have an Enterprise Risk Committee or Operational Risk Committee looking out broadly over the risk landscape. But forward-thinking organizations also empower an IT Risk Committee (reporting to either of those super committees).

It’s a recognition that information technology presents special challenges requiring specific risk expertise.

An IT Risk Committee is also a recognition that technology risk needs to be managed in a proactive way, instead of relegated to an IT Governance Committee, where it tends to be crowded out by operational, budget and staffing concerns.

The committee should be chaired by the Head of IT Risk and, at a minimum, the membership should include:

• Head of IT Operations
• Head of IT Development
• CISO
• Operational Risk Management
• Business Continuity Management
• Legal
• Compliance
• HR
• Lines of business management
• Audit as non-voting member

Bonus points for including PR, Privacy (if not covered by Compliance), Data Officer and IT Architecture. Also, Sales or Customer Support; don’t underestimate their contribution because they have the voice of the client to understand real impact.

Collectively, this broad-based group is well positioned to

• Assess risk management processes against business objectives
• Help articulate risk appetite/tolerance
• Foster a culture that emphasizes a risk-based approach to risk management.

So far so good – but practically speaking, there’s a major roadblock: How committee members from IT, Legal, Sales and the rest of the diverse cast can find a common language about risk to enable effective decision making.

You’d think that the chief information officer or chief information security officer could frame the issues for them. But too often, they speak in terms no one outside IT can understand: compliance with the NIST framework, number of patches or other mitigations, or subjectively arrived at “heat maps” (red for risky, green for safe, yellow for flip a coin).

Another common problem is that IT leaders focus entirely on weaknesses with no context of a risk scenario that is meaningful, and fall back on capability or maturity ratings to evaluate their programs because they don’t know how to measure their actual risk posture.  Communication devolves into tracking activity-based metrics, with no meaningful risk indicators.

The stack to the right shows the way to effective risk management.

It starts with accurate models that enable meaningful measurements that show decision makers the way to comparing options that lead to the informed decisions on the best way to manage risk.

Take another look at the stack from the point of view of the fundamental questions that the IT Risk Committee must answer…

• What are our top risks?
• Are we doing enough? Or too much?

…questions that hang on making comparisons among options that require meaningful measurements based on an accurate model.

Ditto for the tactical decisions the IT Risk Committee must make:

• Approving a risk framework
• Reviewing risk acceptances
• Recommending risk tolerance thresholds to management
• Prioritizing assessment focus areas
• Monitoring significant shifts in threat landscape
• Escalating issues to higher level committees

The FAIR model (the analytical engine that powers RiskLens) was built to answer these needs by translating risk probabilities into financial terms, a common language that every member of an IT risk committee would understand.

To see how FAIR can cut through the fog of fuzzy thinking and show a true, relative ranking of risks, take a look at this short case study:

In a Top-10 Risks Analysis, Get These 2 Factors Right