Moving from Security to Risk Management connects it to Business

One of the more interesting opportunities that I’ve had in my career was to build a security practice and evolve it into risk management practice at a large financial institution (FI). This was especially interesting as the FI was moving from having limited digital touchpoints to having multiple channels, all while consumer expectations were rapidly evolving to require 7x24 services and a seamless low friction user experience.

Security needs to be the priority

The first step in that journey was to bring in someone that was strong at security and understood risk from both a business and technology perspective (very rare at that time). We needed someone that could balance enabling members while protecting their assets.

As this scenario was at an FI, I cannot get into specifics, but the first couple years were focused on more traditional security management, by ensuring systems were at a bank level of security, while the organization took on a strong digital channel footprint. During this time, our audit functions also matured, with several internal and external audits providing a list of deficiencies to work through. We survived that journey by doing a quick risk calculation on the vulnerabilities and addressing what was critical.

Keep Security as a focus and once it is mature, add Risk Management.

The next part of our journey now required us to focus on the audit backlog which was comprised of ISO and COBIT recommendations. This is when the focus moved from security to also include risk. The challenge here, was that the audit findings were typically about vulnerabilities without context for overall risk. The early main activities were:

• Build and gain support for a Risk and Security Strategy. For us, that included:

  • Build risk appetite and threshold policies to guide investment and prioritization as compared to other competing priorities in the company. These are very strategic choices - can you accept risk in some areas to drive growth or speed or innovation?

  • Use the business focused risk appetites and thresholds to guide management reporting to keep executive informed on risk and planned mitigations.

  • Choose a formal framework or methodology to align to (IS0 31000) that would integrate with existing audits (ISO 27001, COBIT) as well as the enterprise’s risk management framework. Adopt the standards from the framework or methodology that help with the largest risks first.

  • Expand the team to include risk expertise and functions. Managing risk creates opportunity by limiting investments into areas that don't exceed your risk appetites, but it does take capacity and skills to get going. It also takes a mindset.

• Build a Risk and Security Roadmap that addresses the Risks. For us, that included:

  • Consolidate audit findings and security team findings into a single Risk Log, to eliminate duplications, rank them for importance to resolve, and identify risk treatment synergies.

  • Build out integrated risk and security processes to streamline execution and accountability based on your chosen standard or framework (e.g. ISO 31000)

  • Build risk tools. e.g. online reporting/monitoring tools and/or risk logs. Excel with PowerBI is fine at first for your log, but consider risk management tools later. Use these templates to bring as much objectivity into risk scoring as possible. We used the RCMP’s Harmonized Threat Risk Assessment (HTRA) method, that breaks risk into threat, vulnerability, and assets). The template was a blend of HTRA, ISO 27001 and ISO 31000. We found it to be very effective at turning an audited vulnerability into a risk, that considers the type of threats (accidental and malicious) that could target the vulnerability and what assets are exposed.

  • Use the thresholds to 'draw a line' on what risks are unacceptable and need action. Identify Risk Treatment options amongst existing planned changes (programs, projects, products, maintenance, etc.). Look for opportunities to address risks within new projects by adding value to business cases. Finally, look at new investments.

  • Build out the roadmap for the treatments. Socialize selectively. Remember, these are your vulnerabilities - so you want to be selective on who needs to know and who can help with funding/support. This is important to get momentum, so some sharing is needed.

  • Gain funding to execute the roadmap – one of the easiest programs that I’ve had to gain funding for, due to the above.

By the end of this journey, we had our greatest sign of a successful security to risk evolution and personal pride of mine – the leader I had brought in to help me build this area, was promoted to become my peer – a VP reporting to the CIO, with complete responsibility for IT Risk and Security.

Key Takeaways:

• Focus on Security before Risk for maturity, then use Risk to manage Security.

• Build out Risk in a way that the business understands. Connect it to the board and executive Enterprise Risk Management functions. This makes it easier to combat noise, gain funding and focus on what is important.

• Develop a separate audit function to compliment and mature security. Work hard at making this a constructive relationship. Audit can identify the vulnerabilities, but doesn’t always understand threats or assets.

• Audit should have a nice list of ‘to dos’ for you. Quantify your risks and roadmap them for mitigation. Leverage opportunities to mitigate risk. Align stakeholders and gain support.

• Execute and Report to gain momentum. Report early and often.

Other insights

• When you create risk logs, quantify in terms of Vulnerabilities, Threats and Assets to help address noise and fears with objectivity. It focuses the conversation on what is important. It can also bring out synergies when mitigations can address vulnerabilities across several assets.

• When you assign risk owners – keep in mind that those that have ‘Motive’ to resolve the risk (Risk Owner) may not have the ‘Means’ and ‘Opportunity’ to resolve it. Consider separating Risk Owners and Risk Treatment Owners (could be several) for better accountability and progress. Risk Treatment Owners are accountable to Risk Owners and now have good objective direction on risk weighting to prioritize their work. This takes good governance.

• Ensure your Log connects to the Risk Appetite and Threshold policies for simple reporting. e.g. if you have a defined appetite for customer data loss, use it. This can then align to your funding governance by distinguishing between non-discretionary and discretionary.

• When setting up your risk calculation (Vulnerability x Threat x Asset), do it for current state when the audit or security team raised it and again for Treated, so that you do not lose the ability to change your treatment options - they do change.

• Diarize every risk for a refresh. More critical, more often.

• Once security risk logs are working well to feed your rolling roadmap, consider adding operational risk to help you find more synergies and opportunities for resolution. e.g. By using the risk log to assess COVID risk in early 2020, I was able to flag Supply Chain risk several months before it emerged in indsustry.

• Use risk thresholds to help you identify what is good enough. This can help you show where you can use a higher risk threshold to enable a customer experience.

• Use risk thresholds to park risks as well. If one of three planned treatments puts the risk lower on the list, think about parking it in favor of more urgent risks vs chasing the last two treatments. This is where methodical risk management can be very powerful.

• Consider targeting your risk calculation thresholds (Vulnerability x Threat x Asset) higher than your policy at first, if you have a backlog. This is to drive a focus on the highest risk (remember, too many priorities often means no priorities) and then bring the threshold down as you make progress. Use this to debate options to invest more to go faster. This is part of your Risk Strategy - informed explicit choices on options.

Though I've talked about security risk, these tools and processes have worked very well in other areas of business, like product management, emerging technology, strategy risk and program execution. When you combine it with ITIL processes like Problem Management, to feed risk treatment options (even if not technology), it can become very powerful at continuously driving down your risk exposure or balancing risk for reward.

If you would like to know more or get help on any of the above, please contact me.