“It is not the strongest of the species that survives, not the most intelligent that survives.

It is the one that is the most adaptable to change.”

 

Charles Robert Darwin, 1809 – 1882

Change is constant, we may like it or not. But it is the truth. It can not be stopped. Change may come from both internal and external forces and requirements. They may be small or big and more or less impactful. What we know, is still, that change is constant. And this is one of those things that Security GRC when it comes to the security universe, can support to manage in a more controlled and systematic way. Managing change is only one part of the benefits that may come from Security GRC. But before we dive further into the benefits and the rest of this article, I will put some more context around the subject –> Security GRC.

GRC stands for Governance, Risk Management & Compliance. This article is about Security GRC.

The purpose of this article is to put my own words on the subject. I have already kind of, in several articles talked about it and explained what it is from each letter in the acronym. But this article will serve as a short summary of what Security GRC is and also shine some light on the why, how, and when.

Security GRC is not something unique to the security industry or discipline. It is a discipline and practice that the security industry has adopted. GRC has been a thing in several other industries before it reached security. Some of these are:

• Finance
• Medical
• Healthcare
• Insurance
• Energy

What these industries have in common, and have had for decades, is that they are highly regulated. SOX is one of the regulations for finance, HIIPA applies to healthcare, and FDA applies to food and drugs, PCI-DSS is applicable when payment cards are used for digital transactions.

These are just a few examples. The list of regulations has through the years increased and still does. Almost each and every industry is today, to some extent more or less regulated. GDPR for example is one of those regulations that impacts a very high span of organizations. In Europe, almost each and every organization is impacted.

Regulations related to AI are another example and when technology drives the the increased need for further compliance through regulations. As you might already know and have figured out, the last regulation that an organization will need to comply with has not been invented or developed at this point. There is more to come and the list will be made longer. The piles of regulations will increase. The requirements related to compliance will not go away.

A commonly confused practice within GRC is the G, Governance. Many confuse Governance with Management. There is a difference and it’s pretty obvious when put into context.

Governance is, short and simple, about the bigger picture and less about the details. It is about setting the direction, strategy, and vision. These “ bigger picture” things are (in general and shall be) the board’s responsibility. The execution of the day-to-day activities is operationalized by the organization and starts out with the CEO. The CEO is not the one who will do all the work but will delegate the responsibility and accountability to the team around him/her, also known as the Executive Management Team, EMT (consisting of roles such as for example CFO, CMO, CIO, CISO, COO, CRO and so forth). The EMT delegates the operationalization, to some extent or fully, to their team members (Vice Presidents, Directors etcetera). The execution of the objectives to achieve the strategy, set by the governing body (the board), is managed throughout the organization.

This is somewhat of a simplified description of how the chain of delegation and governance may take place. Depending on, for example, the operational model and structure of an organization may contribute to the picture looking a bit different. The structure I have described is not set in stone but gives a good overview of the overall idea.

Sorry, I know! The text is very small and might be hard to read. Use the zoom function if possible, I think the illustration is valuable to study.

The takeaway is that the model I described for how Governance can be applied to several parts of an organization to achieve the same outcomes. For example IT Governance, Financial Governance, Business Governance, Security Governance, and so forth. For each part of an organizational entity, a leadership committee (I.e., governance) establishes the strategy.

The strategy for example Corporate Finance is developed by the leadership committee which delegates the accountability and responsibility for managing the execution of the objectives to the roles and responsibilities in the Finance organization to operationalize the strategy.

The Corporate Finance Strategy is not something that takes place in isolation, it is aligned as a part of the overall corporate strategy in direction with the board’s strategy for the organization.

Properly established Governance will provide control, transparency, direction, ethics, and separation of responsibilities. Generally, Governance is responsible for the “What” and Management is responsible for the “How”.

How things are carried out in reality may though take a different form between organizations. When theory meets reality those may not always align. More or less, every organization has some form of Governance in place that serves as a decision-making body for where those “bigger picture” things are discussed and decided on. And for Governance to function it need leadership. Governance can’t exist without leadership. Establishing Governance does not equate to that leadership being accomplished. These are two different things but they go hand in hand.

There is certainly more that can and should be said about Governance but I will stop here for now. Let’s jump into the What, Why, When, & How explanation of Security GRC.

WHAT?

In this article, Security GRC is explained as:

A structured and holistic discipline covering the practices of Governance, Risk Management, and Compliance, ie. GRC.

As you may see there are fewer wordings in this explanation about “security” or something such as protection, resilience, detection etcetera. These things affect Security GRC or may be an outcome of the work. How the objectives are managed and actualized in alignment with the strategic direction, i.e. Governance.

Security GRC is a subset of Corporate GRC which is focused on the management and oversight of security efforts. This means that Security GRC in an organization is a part of a bigger puzzle as explained earlier in this article. It does not and shall not operate in isolation from the rest of the organization. Security GRC shall be integrated with Corporate GRC, other GRC disciplines, and the rest of the organization.

Security is a team sport and so is Security GRC. This is not something that is a one-man show or something that only is a thing taking place in a security team. This is a discipline that is established to support the organization it exists in. And yes, a tool or software for Security GRC, that helps out to automate things such as evidence collection, risk reporting, and data classification, is and can be a part of the puzzle but this is not a unicorn solution.

Before a tool or software implementation of a Security GRC tool, other things should be established. Let’s call these things foundational components of Security GRC. These things equate to for example structure, frameworks, and processes. And of course, you need to have support for the change from your stakeholders and sponsors. A tool or software should rather, as I see it, be a natural progression in an organization’s maturity journey of Security GRC rather than the absolute starting point.

This principle is not unique to Security GRC though, it applies to pretty much more or less all aspects of an organization’s maturity journey. If an organization does not have people and processes available and educated on a certain subject/discipline/skill/<etcetera> technology will provide less value. I have seen this mistake several times in a bunch of different forms of projects throughout my career. IT Service Management, Risk Management, Identity & Access Management, and Cloud Security Governance just to mention a couple examples. The list could have been made longer but I will stop here for now.

WHY?

The values gained for an organization that chooses to establish Security GRC can provide:

Ensured compliance, mitigation of risks, and contributed to an improved security posture, and cyber resilience in alignment with the organization’s strategic objectives.

An organization that chooses to establish Security GRC will gain positive effects and value addition from managing the three practices (Governance, Risk Management, & Compliance) in synchronization. Each of the three practices within GRC is and shall be seen as a unique perspective which all serve the same overall purpose. Go back to the picture above in the What section and study the descriptions.

The practices together form a system and a holistic structure that operates as a totality. The value generated for an organization by synchronizing and integrating the three practices may for example be:

• reduced or elimination of duplicated efforts
• increased efficiency through the usage of common processes and methods
• increased insight and understanding of the organization’s security and compliance posture
• improved alignment of investments in relation to the organization’s strategic direction

HOW?

The establishment of Security GRC in an organization:

Shall be adapted toward the organization’s culture and not the other way around.

The form of how Security GRC is established may differ between organizations. A very mature organization, for example operating in the Finance industry, will have a more “complex” setup compared to a start-up company developing software. Both these organizations need some form of Security GRC but the practical implementation will differ. The reasons for it, are for example but are not limited to:

• Culture
• Regulations
• Organizational size
• Geographical spread
• Operating model
• Organizational history
• Organizational structure

I think it is very accurate to say that there is no one-size-fits-all Security GRC setup that can be copy-pasted into each and every organization. There are of course general recommendations and principles that make up a good starting point, but these are just that. Even the best theoretical principle or model may not become best friends with security in reality. In this article, I share some of my thoughts about Security in reality.

WHEN?

Security GRC shall be established when:

The organization is mature enough and sponsoring for the implementation is established with key stakeholders.

If an organization is not “mature” enough to establish Security GRC or the decision is not sponsored by key stakeholders the journey should not start. I am by no means saying the establishment is or shall be a cakewalk but if an organization lacks the understanding of “why” Security GRC is needed, the conversation must start here.

A very big part of an organization’s maturity, related to security (independent of its GRC or something else), starts from an awareness point. If the organization and the key stakeholders are not aware of why that security thing is needed this is the starting point. And to establish this form of awareness is usually not something that is accomplished through one meeting or as a quick discussion at the coffee machine.

It is up to you as a security leader to influence your key stakeholders and decision-makers in your organization to understand why Security GRC is needed. You need to create awareness and explain why, what, when, and how Security GRC is needed. If you identify that an organization is in need of it, don’t sit and wait for it to happen. It is up to you to lead the way. You need to influence your organization to realize the values of it. Communication. It’s up to you as a security leader.

EPILOGUE

Most organizations have some sort of Governance established. In some places, it is more formalized, in other places less. My observation of why this is the case is due to what an organization requires or how mature they are.

Just because you as a security leader identify the need for an organization to implement Security GRC does not mean they are mature enough for the change. Or that they actually need it in the way you want to implement it. And the key thing here is “change”. Change requires inclusion and to create inclusion leadership is required.

How big is the change? How fast is the change? How <insert> is the change? What we know about change, is that it is constant. Adaptability is key. The reality will constantly be changing.

Implementing Security GRC is a change, small or big of course depending on where the starting point is…as I explained earlier in the article. Adopt the change and establishment of Security GRC to fit into your organization, it will never, or with a very small chance, work the other way around.

And implementing Security GRC is not about implementing a certain tool or software. This may be a part of the establishment but should not be the first place or starting point. This is how many organizations do it, and I understand it. Going with a tool/software implementation before the establishment of adequate core processes and structuring, such as for example a Governance structure & framework, Risk Management framework & processes, Compliance framework & auditing processes will most likely turn out in a less optimal outcome. I wouldn’t recommend the starting point to be from a tooling/software orientation. It should be the other way around –> structure, frameworks, and processes.

You are the expert who is there to show the way, know the way, and go the way. Actions speak louder than words but before you start taking action on this subject, make sure to have your sponsors and key stakeholders with you on the change. This is key to any change.

Link to original article – Click Here
Follow Henrik Parkkinen on LinkedIn – Click Here
Visit HenrikParkkinen.com