In any sizable organization it is important to have some form of management steering group or committee to oversee your risk program.
The following practices are some of what I’ve seen work in many organizations, large and small, across many sectors and for programs of varying degrees of maturity. Although, as ever, the golden rule applies that what is right is what works for your organization, operationally and culturally, irrespective of advise from others.
Note: there are some formality differences between committees, steering groups, councils or other constructs. But, for the sake of this post, let's just take them to be the same thing and refer to them as steering groups.
Don’t be Information Security or Cybersecurity Specific. Yes, that’s right, as much as you can [you might not be able to because of some regulation] move away from a steering group that focuses on one topic only. We’ve talked before that cyber isn’t the only technology risk and for these reasons it’s crucial to not have discussions of cyber out of context from wider technology strategy and risk mitigation. Planning and directing an integrated approach to how software lifecycle, operating, resilience, data governance and other risks will be managed will ultimately create faster and more sustainable mitigation of information/cybersecurity risks.
Don’t Always Cover Topics Once Only. This may seem counter intuitive for efficiency. In other words, if you have a Technology/Information Risk steering group then all things related to those risks must only be covered there, right? No, you need to make this topic be present across your governance apparatus from the Board through to executive leadership's other risk and operating governance structures. Your goal is to make information/cybersecurity a first class business risk and so you need to cover it in strategy, budget, product approvals, acquisition/divestment and other organization processes, which also means curating the topic for discussion at the governance apparatus that oversees those processes - but the topics will need to be covered in ways appropriate for that, and so.......
Don’t Duplicate. Avoid taking people / teams through multiple steering groups to present the same topic or risk discussion. This is not only onerous for the people who need to get the work done but can also introduce confusion in the accountability of where risk tolerances are set. However, there will usually be a need to cover the same topic through different lenses, for example: a major IT migration might be examined at a Technology/Information Risk steering group where specific technical, security, and other risks are reviewed, but there may also be an executive committee or an enterprise-wide risk group that needs to see the perspective of how business and operational risk will be managed through the transition.
Balance Membership. Membership of a steering group should be balanced according to expertise and contribution in favor of organization chart driven representation. However, this is highly culturally sensitive especially if the steering group is a place where policies are reviewed and approved. Although, for that case I’d argue it’s important to build consensus as much as possible in the policy and strategy development process outside of the steering group.
Make it Interesting. This should be a meeting that people look forward to attending and contributing to. Some approaches for doing this include: - Examining risks in the context of scenarios (narratives of situations that might arise and how you would deal with them vs. what residual risks need attending to) - Examining incidents, close-calls or incidents that have occurred elsewhere as a means of learning and directing improvements. Build a process where incidents that have recently occurred get priority discussion while it’s fresh in people’s minds - Reviewing new programs / initiatives and the approaches to risk mitigation. This could be new business activities, new technology programs through to acquisitions or joint ventures - Conduct pre-mortems of product or other major launches to use the collective expertise of the group to plan for negative outcomes - Avoid any time being spent of things that might be considered a “posting”, those can be done in e-mails or pre-reading - Look for the adjacent commercial benefits of risk management. Steering groups focused on risk are not just about reducing risk. Some of the most vibrant discussions can be about keeping risk at the same level but changing the controls to improve customer experience, efficiency or cost.
Make it Structured. All the materials used should be of a standard format, tone, language using specific templates and visual cues so that over time people can immediately orient to the essential information to make decisions. This can include: - Risk Cards. Standard templates to illustrate risks, mitigation, continuous monitoring for that mitigation and any residual risk - especially the path by which such residual risk might be realized and how that will be handled - Incident Cards. Templates for describing incidents or close-calls including timelines, 5Y’s root cause analysis and actions needed - Scenario Cards. There may be some necessary variance in how scenarios are described but the basic layout and visual style can be consistent - Issue Card. A very specific template that describes an issue, the considerations and the decision options. Construct these to avoid the need (or excuse) for a decision to be pushed elsewhere or otherwise delayed. This type of content takes a lot of work to prepare but results in a more efficient decision making process.
Relentless Follow-Up. Capture actions and track / review them for completeness. Have a standard agenda item to review late actions. Don’t just capture and focus on the actions that were explicitly made or discussed at the meeting but also the actions that were implied in any of the contents presented that may not have been discussed. Require such actions be captured in a work tracking or issue management system. If you’re in a regulated industry you are likely going to need to keep good records of the meetings including having your Legal and Compliance teams ensure that discussions are captured in the right way.
Metrics and Exceptions. Don’t expect the steering group to review / pore over packs of risk indicators or metrics. Rather the risk team or steering group staffers should call out discrepancies or variances to be framed and discussed as an Issue Card.
Identify the Interplay of Risks. The risk team / steering group staff should be doing the work to identify seams or impedance mismatch between risk programs or different parts of the technology stack / environment. Any issues should be framed as Issue Cards to discuss. One of the most valuable parts of this work is for the risk team to be on the look out for repeat issues, or repeated themes that would require the curation of some broader risk mitigation work.
Don’t be the Sole Chair. This will be highly organization / culturally specific, but in general I think it is powerful for the Chair role of such a steering group to not be the CISO, or at least the CISO (or another risk executive) should co-Chair with another business or technology executive. Having other leadership drive the work sends a powerful message to the organization and also makes that other leader immensely vested in the work as part of their day to day role. I’ve seen some leaders who initially were reluctant to drive this work ultimately became some of the most powerful advocates as a result of taking on the Chair role. Finally, your role as Chair (or co-Chair) is to make the meeting work - not to dominate the discussion or use this a pulpit.
Manage Membership. Steering groups like this will need different expertise over time and there’s no harm in regularly changing membership - especially given many ex-members will continue to be forceful advocates across the enterprise. It’s also important to encourage participation from some members and perhaps ultimately replace people who are not contributing over an extended period. For new members, don’t just drop them into the steering group, put in a place an “on ramp” where they can be educated on past topics, structure, and some basic overview of concepts that they might be unfamiliar with.
Take a Customer Perspective. Most enterprises are incredibly customer centric and, therefore, action is highly motivated by taking the perspective of the customer. Framing the work of the steering group in that context, especially scenarios and incident close call reviews, inevitably helps establish what appropriate risk tolerances are.
Publish a Forward Agenda. Regularly solicit member input to set and publish a forward agenda (at least 3, perhaps more, meetings ahead). Establish a formal process for setting agenda items based on enterprise processes such as product management, strategic planning, major initiatives, new technology developments and major business transactions. Periodically map the agenda to your risk taxonomy / risk register to look for blind-spots of important risks that might not have been receiving sufficient attention.
Bottom line: A well managed Technology/Information Risk steering group should be a vibrant discussion forum and a hub for managing the alignment of these risk topics consistently across the whole enterprise. When things go well, like a major event avoided, remember to thank the steering group members for their efforts in supporting your and other teams to get to that state.
Comments