What GRC actually stands for (and why that matters in practice)

Everyone who works in GRC has a definition of GRC. Most of them are different from each other. This is a short article to settle on a useful one, and to explain why the three letters exist and what goes wrong when they are treated as one thing or three entirely separate things.

A short history

The phrase "governance, risk, and compliance" started showing up in the mid-2000s. It was an attempt to describe, in a single category, three disciplines that had been growing up alongside each other: corporate governance (the board and executive oversight of the organization), risk management (the identification and treatment of risks across the business), and regulatory compliance (the operationalization of legal and regulatory requirements). Before the phrase existed, these lived in different rooms. Governance was a board conversation. Risk was a CRO conversation, if the organization had one. Compliance was a general counsel or chief compliance officer conversation. GRC was the word someone invented to describe the idea that these three should talk to each other.

Why they need each other

Governance without risk is just policy: who decides what, with no information about what could go wrong. Risk without governance is just a list: what could go wrong, with no one empowered to do anything about it. Compliance without risk is a checkbox exercise: we met the rule, and also we have no idea how likely the thing the rule was trying to prevent actually is. Compliance without governance is a chore: someone wrote the policy, but nobody is accountable for it. The letters only make sense together because the underlying disciplines only deliver value together.

A working definition

GRC is the discipline of running an organization in a way that makes its governance, its risk-taking, and its compliance decisions explicit, accountable, and reviewable. 'Explicit' means the decisions are written down, not assumed. 'Accountable' means there is a named person who owns each decision and can be asked about it. 'Reviewable' means the decisions can be inspected after the fact — by an auditor, a regulator, a board, or the person making the next decision.

Three common misconceptions

First misconception: GRC is a tool bucket. It is not. It is a discipline. Tools support it; they do not define it. Second misconception: GRC is a framework. Also no. Frameworks like SOC 2 and ISO 27001 are inputs to GRC, not GRC itself. You can run a GRC program against many frameworks, or against none of them. Third misconception: GRC is an audit function. It includes audit concerns but it is not the same as audit. Audit looks at whether the program is working. GRC is the program.

How a modern GRC function organizes itself

Most mid-size organizations end up with three or four people reporting into a head of GRC: a compliance manager (running the frameworks), a risk analyst (running the risk register and the risk conversations with the business), an audit liaison (running internal and external audit engagements), and — in more mature organizations — a regulatory change analyst (tracking new regulations and amendments). At larger organizations these roles multiply and specialize. At smaller organizations one person wears several hats. Either way, the discipline is the same.

Where the rough edges are

The biggest rough edge in most GRC functions is the boundary with information security. Security and GRC overlap because both care about controls, and both care about evidence. The most successful organizations we have seen treat the security team as the owner of most technical controls and the GRC team as the owner of the program that holds those controls accountable. When the two teams are at odds, the program always suffers. The second rough edge is the boundary with legal — legal owns the interpretation of laws and regulations; GRC owns the operationalization. When those two boundaries are clear and respected, the program runs smoothly.

Tags