Strategy, Frameworks and More Frameworks

Last time, I discussed how you can step up as a leader and help define the cyber risk appetite for your organization. As a reminder, COSO has 5 guiding principles and we are at the second guiding principle of Strategy and Objective Setting.  This principle is comprised of four points:

1. Analyzes Business Context

2. Defines Risk Appetite

3. Evaluates Alternative Strategies

4. Formulates Business Objectives

This week, we’ll tackle the 3rd point -- Evaluate Alternative Strategies

An organization must evaluate alternative strategies as part of defining strategy.  You must assess each option’s risk and all opportunities in conjunction with your organization’s resources, in order to create, preserve and realize real value.

Enterprise Risk Management involves evaluating strategy from two perspectives:

1. The possibility that the chosen strategy will not align with the mission, vision, and core values of your organization; AND

2. The implication of the chosen strategy.

For you as a cybersecurity leader, the chosen strategy in this context translates to defining a set of frameworks to oversee the cybersecurity risk management program.

Several cybersecurity frameworks such as the NIST Cybersecurity Framework, ISO 27001, and Service Organization Control (SOC 2) have been developed to help organizations establish and report on the effectiveness of their cybersecurity program.

The selection and mapping of those frameworks to technical security controls and risk management processes is also often referred to as the organization’s information security management system (ISMS).

You must determine which framework to leverage to build your ISMS by considering which is the best fit based on your business operations, current control structure, and various other factors such as capital, technologies, and resources.

Here are a couple of things to consider:

1. Understand the environment within which your organization operates. In other words, you must understand your business’ context.  I talked about this two weeks ago, and you can see that video on LinkedIn or on the website.

   o   For instance, ISO 27001 is costly and resource-intensive to implement and, for most organizations, it is optional.

   o   PCI DSS may be costly and resource-intensive to implement, but it IS required for organizations that store, transmit, or process credit card information.

   o   Just think of a cloud-based government healthcare payment processor. They likely have to worry about FedRAMP, PCI DSS, AICPA SOC2, and HIPAA/HITRUST (ouch).  Not to mention privacy regulations, such as GDPR, and CCPA. 

2. All THAT is why normalizing your internal GRC framework is a must.

   o   Otherwise, you will find yourself in perpetual audit hell.  Figure out where the overlaps are between your various requirements and build your GRC controls accordingly.

   o   The last thing you want to do is measure your program effectiveness differently based on the requirements of the next audit you have to pass.

   §  Doing that is called “compliance-based security,” and, THAT quickly turns into “checkbox security,” WHICH turns into a breach!

   ·  Target had just passed a PCI audit when it had its significant breach back in December 2013.  Compliance does NOT equal security!

   o   Let your security program drive compliance to your required frameworks and, not the other way around!

Next time, I’ll continue to the 4th point -- Formulate Business Objectives.

As always, I love your comments, and if you want to have a direct conversation, please shoot me a message and we’ll set something up. Thank you and have a great week.