The impact of GRC Engineering on Third-Party Cyber Risk Management
The GRC Engineering manifesto suggests a change in how we approach governance, risk, and compliance (GRC) with the goal of making related processes more automated and effective. The path to achieving these changes comes from a list of fundamental values, but the two we want to focus on today are: aligning the goals of different teams within an organization so that they are working towards the same outcomes, and striving to make those outcomes consistent and measurable.
With concrete, quantitative goals in place, an organization can then replace outdated and inaccurate solutions checkbox surveys and periodic monitoring with continuous, always-on assurances.
More succinctly, GRC Engineering encourages inviting outside contributions and centering policies around technology and our ever-improving understanding of cybersecurity threats.
As it happens, Third-Party Cyber Risk Management (TPCRM) is often within the scope of GRC processes. Businesses look at their third parties as entities that must be evaluated through time-consuming assurance tasks that exist outside of the work that they will perform. In a broad sense, this is the same issue that the GRC Engineering manifesto raises about many lines of GRC work.
So what would this shift look like in practice when it comes to assessing third-party risk, and especially third-party cyber risk?
Optimization, technology, and automation
It's quite intuitive to start solving a problem by developing a manual process. Unfortunately, manual processes can run into scaling challenges, which naturally leads to a situation where people settle for limitations in scope. In the real world, this may mean performing an assessment once a year, or only evaluating a subset of a business.
This clearly harms the effectiveness of the processes, but it's difficult to find a solution while bound by the expectations and the workflow set by the established procedures. Trying to automate an existing process will often lead to simple adaptation of a set of potentially flawed (or simply limited) steps, rather than designing something efficient that is guided by the original goals.
It might be possible to automate these tasks, but it's very likely that the automation will be clunky and limited. Instead, a better approach is to look at the technology landscape and design a process that is made for automation from the ground up. To illustrate, it would be a bit like refusing to develop a vehicle unless it has legs because that's how we learned to go from point A to point B, even though technology can achieve our actual goal (movement) in a much more efficient manner.
When looking specifically at GRC Engineering, you'll find resources detailing its implementation in modern cloud environments. The core philosophy is to embed these principles into the organization's technical fabric. As Michael Rasmussen, a seasoned GRC expert, stated in a GRC 20/20 article: "GRC engineering is the discipline of embedding governance, risk management, and compliance into the technical fabric of the organization through systems architecture, automation, and data engineering. This perspective, combined with thoughts from Ayoub Fandi, Security Assurance Automation Team Lead at GitLab and founder of the GRC Engineer Podcast & Newsletter, highlights the industry shift toward operationalized GRC. Again, technology is key.
The same opportunities also exist for TPCRM. Instead of looking for ways to automate processes designed to be manual, such as questionnaires, we need to consider the technology environment and then design solutions backed by that infrastructure.
There is a lot that can be done in cloud systems (and connected environments in general) to automate third-party risk management, but many of these possibilities will only become apparent when we consider how the technology works and our goals. When it comes to cybersecurity, the goals should come from our understanding of the threats and risks.
Threat defense and outcomes over standards and formalities
Standards are very useful guidelines. But sometimes they are treated as the goal itself, leading to what the GRC Engineering manifesto calls the "commoditization of compliance."
When a standard leans too much into being "useful" as a convenient evaluation metric, it can unfortunately detach itself from the real-world problem it was meant to solve.
For GRC, this is most evident in SOC 2 Type II audits (check out our bonus podcast episode on SOC 2). This has a direct impact on third-party risk management, since many organizations will request such audits or security certifications as proof of compliance to find "trusted" third parties. Unfortunately, because these assessments do not necessarily translate into real-world results, businesses are not always getting the assurance they're hoping for.
When the same idea of outcome over formality is more directly applied to TPCRM, it raises the question of whether an evaluation is just paperwork, or if we are truly learning something of value about the third party. Following up on that, it's important to know if the things we learned are connected to the threats and risks we want to mitigate.
This line of thinking changes the game in a couple of ways.
First, it means that understanding the threat landscape is valuable for your TPCRM program, and that this knowledge should inform your requirements and evaluation methods.
Second, it'll be very apparent that time is an important variable, because risks and threats are linked to timeframes. It's not possible to promptly adjust your assessments without a process that is dynamic, flexible, and continuous.
If you are already using threat data to inform your GRC decisions, the same approach can naturally spread into your TPCRM program.
What if your third party uses GRC Engineering?
It can be difficult to change our way of thinking, especially when there won't be a simple and universal framework to guide each step. Consequently, if a third party applies the principles behind GRC Engineering to improve their outcomes, they might be expected to also perform the same manual work that everybody does.
This is a problem. If there is no way to do better without doing more, businesses cannot become more efficient!
It may seem challenging to make assessments without a playbook. But if you use threat data to inform your priorities, you already have one. There is also no need to think of complicated signals that indicate the existence of good security practice when you can simply query the information you are looking for.
For example, you can either ask several questions to learn about your third parties' identity security practices, or you can query their environment to see how many users have MFA and how many don't. Today, a lot of organizations have an IT infrastructure that makes this possible, but many are not taking advantage of it.
Working together with third parties through inside-out monitoring gives you real-world insights about their security practices and is much more focused on the outcomes that have been achieved. In many ways, it rewards efficiency and results, which is what most businesses are looking for. Moreover, it enables a risk management approach that is data-driven without ignoring time as a variable.
We should always be on the lookout for improvements and even better ways to approach GRC and TPCRM. As a first step, though, we must recognize the kinds of building blocks we have available today that we didn't have before, and that migrating old processes into a new landscape is not the best recipe for maintaining the same levels of assurance and compliance.
