Operational Challenges in Implementing Tech GRC

In an earlier post I talked about the why organizations face difficulties as they implement a sound Technology GRC program. As I mentioned, there are three types of factors.

• Environmental, those outside your control
• Strategic, how you choose to respond. And 
• Operational, how your response is implemented, which is a big topic. I will be discussing in this blog.

As organizations formulate and mount Integrated Risk Management programs to manage their Technology GRC, they find themselves subject to the realities on the ground. The success or failure of these programs depends on the realities in the respective organizations.

The “Policy-to-Practice” Gap

One can have the best laid strategy and plans but as soon as you start rolling out your plans you face operational challenges. Reality seems to deviate from plans.     

No plan survives first contact – Sun Tzu

What are these operational challenges? What causes this “policy-to-practice” gap.

In principle, there are two types of operational challenges. Those that that stem from

• Organizational Processes, Systems and Technologies in use, and;
• People, their attitudes, and training

I will talk about the first one of them in this blog.

Processes, Systems and Technologies

As I mentioned, your organization may have the best plans on paper, but their success or failure will depend on how well the execution of those plans can be supported.

Let’s talk about Systems and Technologies.

First and foremost, do you know what you have? Does all that you have work well with each other? Do you frequently update what you have? Or are you running some antiquated, legacy stuff? Do you have a lot of ‘manual’ processes?

The answers are not so obvious. Examples abound otherwise.

Let’s look at these issues in some more detail.

Do you know what you have? World of the Undead!

Over time as we respond to changing needs of our organizations, we implement new systems, change the way we work. As we change, so do the systems and processes that support our work. When we change our systems, we may ‘forget’ or ‘lose sight’ of systems and technological assets that had supported the older systems. And they keep on working in the background, unbeknownst to us. Zombie systems!!!

This is not an isolated scenario. Many organizations have incomplete and outdated IT asset inventories like including shadow IT, SaaS sprawl, and cloud resources.

There are many cases that come to mind.

For example, the case of a server that got sealed behind a wall but kept on ‘serving’ for 4 years. It was only discovered because someone traced a cable disappearing into a wall.

Or, Ghost Scripts that keep running, no one knows about them, what they do, how they do it, just that they get things done. No one has the guts to touch them.

Or, the reports that are not built by anyone, that no one where they are coming from, just that they serve a purpose.

If you want to secure something, you must first know what you have. You can’t manage what you don’t know.

It is very important to keep an accurate inventory of your technology assets.

How integrated are those systems?

The success of the GRC program will depend on how integrated the systems are with each other and with the GRC solution. If various applications are not integrated, it will lead to fragmented data and prevent a holistic view of the risks that your organization faces.

If the tools and applications are not integrated with the GRC solution, and you don’t have a unified GRC framework, it’s difficult to get a complete picture of risks and results in gaps in compliance across the organization. 

Integrated systems help provide real-time compliance dashboards that can help identify emerging risks and to control effectiveness.

How frequently do you enhance technical capabilities?

I have frequently encountered organizations where GRC strategies are formulated for traditional, static technology infrastructure. However, our technology infrastructure is constantly evolving and agile because…

You need to keep updating your technological infrastructure for at least these three reasons – Rapid technological advancements; Changing business needs; and Protection against the evolving threat environment.  

Change is a double-edged sword, while it keeps you abreast of your evolving needs, it also introduces new risks and needs you to keep updating and adapting your GRC processes by keeping risk registers and control mappings current.

GRC is not a ‘once and done’ activity.

A lot of manual processes? Spreadsheets abound?

Manual processes including tasks like evidence collection, policy review, risk assessments that depend largely on spreadsheets and email are prone to errors and inefficiencies, hindering the ability to respond quickly to changes, and to scale GRC efforts. 

It is often a case of one hand not knowing what the other is doing

This carries some additional risks. Manual GRC practices can mean indifferent standardization and wide variation across organizations.

All this often results in inefficiencies, inconsistencies, missed deadlines, incorrect compliances (due to incomplete or incorrect information), overlooked risks and it presents challenges to measuring and managing risks.

Not only do manual processes lead to inefficiencies and inconsistencies, but they are also a reason for Compliance fatigue.

Take Audits for example. Your organization may be subject to multiple

 governing bodies, standards and compliance jurisdictions. Not only does this introduce its own complication, but it also contributes to audit and alert fatigue due to constant requests from internal and external auditors, regulators, and customers.

Repeated manual responses to similar audits mean effort is duplicated and lessons are not reused.

Teams can’t step back and build lasting GRC maturity due to constant firefighting.

So… this is why…

In my experience interacting with several organizations large and small, simple and complex I have found plans getting impacted because they are built on incomplete information, inaccurate assumptions and are supported by systems operating in silos, surrounded by manual processes, drowning in spreadsheets.

This needs attention and it needs to be addressed.

But this is not all. There are human factors that impact implementation of Tech GRC controls as well. I will talk about them in my next blog.