Thursday Thoughts

Thursday, 25 April 2024

Some Thursday Thoughts… Risk Management vs Risk Mitigation (or Why I Almost Never Say Risk Mitigation)

Let’s start with a couple of definitions:

Risk Management: Risk management is the identification, evaluation, and prioritization of risks, followed by coordinated and economical application of resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of opportunities.

Risk Treatment: Actions taken to manage identified risk.

Risk Mitigation: The process of reducing risk exposure and minimizing the likelihood of an incident. It involves identifying potential business threats and taking steps to lessen their effects.

Risk management and risk mitigation are both important processes in how your organization deals with risk. As you can see in the definitions, they are not the same, and shouldn’t be used interchangeably.

As a TPRM and GRC practitioner, I see my role primarily as risk management. Our process is built around the core concepts of risk management: identify, evaluate (assess), and prioritize risks. Then get the right people involved to understand how we are going to treat that risk – answering the question “What are we going to do about this?” That’s the heart of risk management: Understanding what can happen and developing strategies to address those eventualities.

In day-to-day risk conversations, I tend to bias toward using risk management vice risk mitigation. While both need to be discussed, my intended message is that as the GRC and TPRM apparatus, my goal is to inform the organization what risks have been identified and present the analysis and prioritization. In most cases, the organization needs to determine the risk treatment strategy – avoid, reduce, share, etc.

By definition, risk mitigation is part of the risk treatment strategy. Going back to Risk Management 101, the risk treatment options are: avoid, reduce, transfer, accept, and share. Some of us may have other terms, but those are the basics. Risk mitigation means that you take steps to reduce the impact and likelihood of that risk by developing and implementing controls, processes, and other protections. Mitigation does not include identification, analysis, prioritization and communication of risk. In this regard, I’d say that “risk treatment” and “risk mitigation” are similar and somewhat interchangeable.

The bottom line here is that risk mitigation is a part of risk management – the “What are we going to do about this?” Remember, words have meaning. Risk management is the entire process, including treatment or mitigation. Treatment and mitigation are the actions you take to address the risk.

Thursday, 18 April 2024

Some Thursday Thoughts... Where should TPRM live? (Hint: It’s not InfoSec...)

You’ve just told your Board of Directors “Yes, we are launching a full-scope, enterprise-wide Third-Party Risk Management program.” They cheered, they clapped, but most importantly, they approved your funding request. The chair of the risk committee asks “Ok, so where will it reside?”

That is a good question. And there is no right answer – it’s very dependent on the organization. The one assertion I will make is that it’s not with the CISO or CIO. That much we can be certain of.

Why not IT or InfoSec? It doesn’t fit. The role of IT and InfoSec is to build, deliver, and maintain secure, robust, resilient technology and capability to the business, take reasonable actions to safeguard data and business processes, and respond to events in a manner that minimizes impact and loss. An enterprise-wide TPRM program assesses and manages risk across multiple domains: cyber, ESG, financial, compliance, and more. Your CISO and CIO are not the appropriate people to manage ESG and financial risk. Moreover, IT won’t have the visibility to your supplier ecosystem.

Procurement is a good starting place for many reasons. First, Procurement will have the best visibility to the supplier ecosystem and your organization’s methodology for managing the supplier lifecycle. Second, Procurement controls the contracting process. Partnering with Legal and the rest of the business, they can influence contract language to ensure certain risks are managed via contractual agreements. That also allows Procurement to be an “enforcer” of sorts – Put it in policy: “No supplier will be approved until appropriate due diligence has been completed.” (Note: Your organization must define “appropriate due diligence”, but that’s another topic.).

Again, Procurement likely owns the supplier lifecycle management process. TPRM is a vital part of that process. TPRM should both inform and be informed by your supplier management process – Suppliers should be managed based partly on the risk rating, and supplier performance and like data should be used to inform the risk rating. Without appropriate ties, that will become an administratively burdensome task.

The bottom line here is that TPRM should reside in the same place as your supplier lifecycle management program. There should be minimal separation between the two. Ideally, they should be fully integrated.

#TPRM #RiskManagement #Procurement #VendorRiskManagement #VendorManagement #SupplierManagement 

Thursday, 11 April 2024

Some Thursday Thoughts... Don't reinvent the wheel when it comes to risk escalation.

So you've started your TPRM journey and you've identified a significant risk, and your program hasn't established a framework to escalate to the required business stakeholders. In the indomitable words of Douglas Adams, "DON'T PANIC!".

Grab a towel, count to 42, relax, and take a look at your internal risk escalation procedures.

Your organization most likely has some sort of procedure or process to escalate risk-related items to the appropriate stakeholders. That process likely includes information on how to evaluate and prioritize risk. It may include things like templates, examples of required information, and priority-based escalation timelines. The kicker here is that your 3rd Party risk is risk, and your internal processes will work to get the right information to the right people. There may be a need to slightly modify the process, but that's OK.

Reinventing the risk escalation process for 3rd Party risk is undesirable for a few reasons:

First, it can be expensive. Maybe not in dollars and cents, but in time and administrative burden. Time that could be spent identifying and managing risk.

Second, it introduces unnecessary redundancy. Which can also be expensive, and will only convolute a risk management framework. (See first bullet).

Third, senior leadership approved the existing policy for a reason - it is structured to give them the information needed to make a decision. Work within that framework, and you'll further ensure the validity and value of the program.

I'll also add this applies to almost every process you'll develop for a TPRM program. So when in doubt, consult the existing procedure. And above all else, relax, count to 42, and most importantly, DON'T PANIC! 

#TPRM #risk #grc #riskmanagement 

Thursday, 04 April 2024

Some Thursday THoughts... 

Research shows 336 publicly disclosed data breaches in the United States - in January 2024. That represents about 7% of disclosed incidents worldwide. For reference, 336 is 7% of 4,800 (admission - I used a calculator for that).

Now add to that those that weren’t disclosed. That’s a lot.

How many of those are your third, fourth, Nth parties?

As #TPRM practitioners, part of our job is to enable our organizations to better anticipate and respond to loss events like data breaches. That requires effective communication. Effective communication requires that we frame risk in terms the organization understands. Communicate in a way that resonates with your stakeholders.

My favorite questions to ask are “What happens to your business process if this supplier can’t supply?” and “What happens to the business if you can’t complete your process?”

How many of those 4,800 January breaches meant that a customer or client couldn’t complete a business process or deliver a product or service? And how was that known universe of risk communicated? 

Wednesday, 3 April 2024

Once again, it's not Thursday but... 

I joined Black Kite's Jeff Wheatman to talk buddy movies, key players in maintaining a secure ecosystem, and tips for communicating third-party cyber risk to the C-Suite. Check out Episode 40 of Jeff's Risk & Reels Podcast! (And all of the other episodes while you're there.)

Monday, 29 January 2024

I know it's not Thursday, but time for some Thursday Thoughts coming into the new year...  What’s your TPRM mantra for 2024? Mine is “Fuse the Cyber”.

But what does “Fuse the Cyber” mean? It means leveraging our full scope of cyber and information security capabilities and competencies to continue delivering actionable risk intelligence and helping the business make informed, risk-intelligent decisions.

So why am I going into 2024 with the mantra “Fuse the Cyber”?

1. Third-Party Cyber Risk Management has a duty to deliver risk intelligence and enable risk management strategies. A good GRC program should have those processes in place. There’s no need to reinvent the wheel with reporting and managing third-party cyber risk and risk vectors. Let’s leverage those processes.

2. Threat-informed risk assessments can enable better risk prioritization. If we understand the threat environment and its influencers, we can better position ourselves to deliver actionable intelligence. Changes in the threat environment will impact the weight we place on certain control groups. It will impact how we view certain risk factors and control gaps.

3. TPRM has a role in incident response. TPRM practitioners should work with their incident response teams and other stakeholders to understand what that role is, and include it in IR plans and playbooks.

My bottom line: Cyber Fusion is the unification and integration of all security and security-related functions. TPRM is a security-related function. So let’s Fuse the Cyber.