Governance, risk, and compliance, commonly referred to as GRC, has been a component of legacy security dogma and cyber security programs for years. It was created during a time (near the early 2000’s, depending on who you ask) when any definition of a security program was considered valid. Because of this, it persists in cyber security programs today, despite how little sense it makes because of its nebulous and conflicting nature.
Cyber security is an industry that needs everyone on the same page to make progress. When you use nebulous or poorly-defined words, it causes confusion. But GRC isn’t just confusing — it has led to a whole host of other issues.
Governance, Risk, and Compliance are Discrete Areas of Business
While the three areas of governance, risk, and compliance are meant to support each other in a security program, it’s difficult for them to function as a single unit. Each of these areas approach cyber security at different times within the security pipeline.
The security pipeline, a term coined in my first book, CISO Handbook, is the manner a security program can influence security in an organization. There are generally three stages in the pipeline in which a program can cause influence: before something goes into production, while it is in production, and after something is implemented and running within an environment.
A security team can influence or change security before it goes into production through architecture or governance activities. A team can also influence things while they’re in production through firewall management or other types of operational activities. Finally, security can influence something after it’s been put into production through compliance activities such as audits or assessments.
Governance, risk, and compliance activities operate at different areas in the security pipeline, which means they don’t work cohesively when they’re grouped together. Governance operates in the pre-production phase, risk operates across the entire pipeline, while compliance operates in the post-production phase.
Each of these processes also requires different approaches and skill sets that rarely operate well together, leading to inefficiency. A risk resource is a very different person from a compliance resource.
This leads to inefficiency and confusion caused by the lack of understanding both within the GRC team or effort, as well as within the organization itself by those in which the team interacts. Finally, the team is only part of the confusion, then you have the category of GRC technologies.
Reliance on GRC Technology
GRC is already a confusing term. Adding “technology” to the end of it just makes it more confusing. This leads to the issue of conflating GRC processes with the tools that help automate these processes.
Because of this, organizations implement a GRC technology and then don’t bother to define their governance, risk, and/or compliance processes as they believe the tool is the process. All they end up with is a misconfigured technology that no one understands, and no clear definition of the associated processes in place.
But GRC issues don’t just manifest in our security policies. For some reason, we’ve applied financial accounting practices to the industry as well.
Security Assessments versus Financial Audits
Maintaining the distinction between remediation and auditing practices works in fields like finance and accounting. It makes sense because the story is easily defined in numbers and the auditing practices have been in place for centuries (AICPA has been around since the 1800s). But in security, many concepts are often unique to the organization, which means they get lost in the translation from audit to remediation.
You wouldn’t have one mechanic tell you what’s wrong with your car and then go to another mechanic to fix it. When you do this, you lose all the insight and understanding from the initial inspection and review, as well as the story of how to fix the problems through remediation. But many boards and executive teams still believe and associate a security assessment with a financial audit, and as a result add a great deal of inefficiency with improving their security efforts.
Unless a security review is especially associated with a compliance or audit requirement, and if the overall goal of your assessment is to aid in improving or fixing identified issues, then assessments should be designed to preserve both the problem and its context with remediation in mind.
This is achieved by using assessment resources that are skilled in the art of remediation, as well as removing conflict of interest requirements that cause more problems than the issues they are designed to solve. This way, your remediation projects can be accurately scoped and tailored according to your organization’s goals.
Some organizations are taking another approach though. Instead of using an assessment, they turn to automation with the latest “diet pill” in the cyber security industry — the cyber risk score.
Cyber Risk Scoring
Cyber security scores or ratings are on the rise. But at best, they’re often used as a quick fix for performing risk management internally or with third-party partners. The problem with these risk-scoring methodologies often falls in their scope and method.
Cyber risk scores often don’t effectively measure risk in many situations because they don’t have access to all the required inputs in order to be accurate. Instead, accuracy is replaced with speed and ease of implementation.
In the world of cyber security, accuracy is important and there are no quick fixes. The only answer is in effective inputs and scope, coupled with good process design and implementation.
So, what do we do?
What Will Happen to GRC?
It’s simple. Our approach to GRC must change.
In its place, organizations must focus on clear definition of governance, risk, and compliance processes. Organizations can start to automate repetitive process steps with the appropriate technologies, but the most important part is clearly defining governance, risk, and compliance roles and responsibilities within a security program with strong process design.
Until this happens, security programs, and the organizations they are designed to protect will continue to be lost and confused.