• Christopher Patteson

Integrated Risk Management on a Page



I started creating these “on-a-page” tools a few years ago while I was in Information Security. The objective was to cover all of the elements of the Information Security / CISO domains in one view.


I'd like to share with you a tool I've created to capture the essence of Integrated Risk Management on a page. So your first question is likely why do I need this? Why should I care?

When I was in Information Security at an organization, I would use these documents in discussions with Finance / Business teams who would often ask “what do you guys actually do over there?” , “what does all of that security funding go to?”. Laying out the entire space on one page also allowed for discussions around where our organization was doing well or where we needed to shore up capabilities.


So, these types of tools serve two purposes:

  1. Education for other business units on the complexity and scope of the domain

  2. Tool for discussing GAP analysis and strategy – Current State, Desired State, what do we need to do to get there.

Over the years I built these, and modified them for the Infosec/ CISO domains. After a conversation a few weeks ago with some other practitioners, I realized that there was a gap. I had not come across an example that defined this at the higher level of Integrated Risk Management - IRM. (Information Security being a subset of IRM).


I was also driven by the results of a recent LinkedIn poll I ran recently.


While 16 votes puts statistical significance into question, the fact that 69% of the respondents did not have a Corporate Risk Officer function, directionally suggests there a lot of siloed teams out there.


In my experience these are often disparate teams of InfoSec, Compliance, Audit, Security, Safety, Operations, and Finance likely working in their separate domains with a limited view/ vision as to what an Integrated Risk Management program looks like in organizations with a Corporate Risk function. This type of siloed orientation often leads to waste in overlapping or redundant controls, and other inefficiencies and gaps in the overall risk program. Further, it increases cost at the operational level as teams answer many of the same risk questions for multiple risk domains.


For those less familiar with the concept of Integrated Risk Management, it is defined as an approach to integrate strategic, operational and IT risks with a comprehensive view across specific risk domains, such as Business Continuity, Vendor Risk, Audit, etc. Many organizations (even those without a stated IRM strategy) are moving in this direction to better support the dynamic nature of risk and increased executive level focus on risk-based business decisions.


How to read the Tool


This is how I use the Integrated Risk Management on a page tool to hold discussions with team members on the first line or when working to identify next steps or gaps.


At the top are two foundational sections. Companies rarely attempt to build their programs to address all Domains and all Frameworks / Standards/ Regulations at the same time. Organizations should target domains with high overlap and pick a framework to move forward as a starting point.

  • Risk Domains – Define the various domains under an integrated risk management program. In today’s highly integrated operations, there is often overlap in the risks and controls. For example, a CyberSecurity risk could have a massive impact on Operational continuity.

  • Frameworks / Standards / Regulations – The next level down is what are often referred to as “the checklists”. This is where traditional GRC programs focused their efforts. Compliance with these various authoritative sources. Each risk program I have reviewed uses a different mix, there is no one right answer.

  • Frameworks and Standards - serve to provide guidance and governance to the structure of programs, and best practices. They help to define Governance and how you will test the Compliance of mitigating controls and program execution. I often call this “big C” compliance because it spans across how controls mitigating risks will be managed in an Integrated Risk program.

  • Regulations - Regulations tie to “little c” compliance. Why little “c”? Failure to comply with these regulations is just another risk – it has a likelihood and a cost if you fail to comply.

  • For new programs, start small, map to the frameworks or standards that have the most impact to your business and best fit your operating models.

The sections below the two foundations tie into a generic risk management framework of Identification, Analysis, Treatment, Implementation, Re-evaluation. This is very similar to continuous improvement cycles found in other disciplines in an organization. There are more detailed and varied models of these cycles in the various frameworks – NIST, ISACA, ISO, etc., The goal in the tool is to layout the generic process and the many activities associated with managing a risk program.

  • Identification – Identification can start by maintaining a simple risk register, but in a large organization with many trade offs this can entail some fairly complex data collection using questionnaires or data feeds from other systems to collect risk telemetry.

  • Assess, Analyze, Prioritize – In this phase there needs to be some level of triage and prioritization. In many cases this is where organizations will apply heat maps, semi-quantitative analysis, and light monte carlo simulations to tease out the risks with highest impact compared to others. In this phase items identified as High Risk may also be targeted for more intense analysis such as Bowtie or Open FAIR

  • Define Treatment / Plans – In this phase risk plans are defined, along with how the risk is going to be treated and managed. Further, any risk that requires controls or countermeasures to mitigate will also need to move into a “control compliance” program to ensure that they are functioning as designed. This also ties into Audit planning processes.

  • Implementation– This is the rollout and execution phase where progress and exceptions are tracked. Activities in this phase can resemble traditional project management, such as tracking, progress metrics, remediation, and exceptions management.

  • Re-evaluate – Once the treatments are rolled out, they need to be monitored for effectiveness. This can be accomplished through manual “questionnaire like” assessments or automated to reduce impact to operational teams. Information from re-evaluation is fed back into the next cycle or as part of continuous monitoring.

Wrapping things up


I hope that this tool will be useful for Integrated Risk Management teams that are looking to analyze their programs for gaps in their existing IRM Strategies. For teams that might just be getting started, I hope this provides a baseline for discussions with leadership on how the risk domains can work together to improve the investment in overall risk management and mitigating countermeasures.


If you are interested in learning more about how your organization can seize the potential of integrated risk management read our The Path from GRC to Integrated Risk Management whitepaper.