00.01 What is GRC?

Why this matters

Governance is the discipline of deciding who gets to decide. It's the policies, committee charters, approval thresholds, and written record of "this is how we make decisions about risk and security around here." When a new vendor request shows up, governance answers who reviews it, by what criteria, and whose signature ends the conversation. Without it, a security program runs on whoever happens to be in the room.

Risk management is the discipline of finding, measuring, and acting on what could go wrong. It's the running register of known risks, the scoring methodology that says one is worse than another, the treatment plan attached to each, and the cadence that keeps the picture current. The job is to answer "what could hurt us, and what are we doing about it?" before someone in a board meeting asks.

Compliance management is the discipline of demonstrating that the controls you said you operate are the controls you actually operate. Frameworks (ISO 27001, SOC 2, NIST CSF, the long list) describe what good looks like; compliance is the evidence trail kept current enough to survive an audit. Compliance isn't the goal of a security program. It's the proof.

Three disciplines, three different jobs. They share an acronym because they share a center of gravity: how an organization handles the gap between intention and reality. Governance writes down the intention. Risk management surfaces the gap. Compliance proves the closing of it. Take any one out and the other two fail in predictable ways. Risks without governance drift toward whatever the loudest engineer worries about that quarter. Governance without risk discipline produces policies nobody reads, because no register ties them to anything that could actually go wrong. Compliance without either is what auditors call a "paperwork program" — the report says one thing, the practice says another, and the gap shows up the first time something breaks.

GRC isn't an org chart. The smallest functioning programs we see have one person running all three in their head; the largest split each across full teams. The work itself is the same: govern, measure, and prove.

How frameworks describe this

The major frameworks each describe the same three disciplines using different language and different emphasis.

• NIST doesn't ship a single document called "GRC." The practice is assembled from three pieces. The NIST Risk Management Framework (RMF) describes the risk side — seven steps from Prepare through Monitor that walk an information system through categorization, control selection, implementation, assessment, authorization, and monitoring. NIST SP 800-53 supplies the control catalog RMF selects from, and its access-control families (AC-2, AC-6, AU-6) carry the governance discipline through least-privilege and accountability. Together, they describe a working GRC program; in isolation, none of them does.
• ISO/IEC 27001 Information Security Management Systems — Requirements is the closest single standard to a unified GRC system. An ISMS is structurally a GRC program: governance from the documented management commitment and policy framework, risk management from clauses 6.1 and 8 (with the methodology in ISO/IEC 27005 Information Security Risk Management), compliance from the Annex A control objectives plus the audit and management-review cycle. A program certifiable to ISO 27001 has all three disciplines working, by definition.
• COSO Enterprise Risk Management frames the practice through a strategic lens, placing Governance and Culture as its first component, ahead of strategy, performance, and review. The ordering is the point — governance isn't the closing wrap on a risk program but the soil it grows in. That's the boardroom view, the right one when the audience is the audit committee rather than the security team.

Use whichever anchors your program. The three disciplines don't change shape between them.

How SimpleRisk implements this

The User Guide is structured around the three disciplines as separate chapters: Risk Management (chapter 01), Compliance Management (chapter 02), and Governance (chapter 03). The split reflects a belief that each discipline has to be practiced on its own terms. A compliance program built on a register nobody reviews produces audit findings; a governance practice without a risk register produces policies nobody enforces. We split the chapters because the work is split in real life.

The rest of this Foundations chapter builds on that frame: the GRC program lifecycle walks the identify-assess-treat-monitor-report loop across all three disciplines, Introducing SimpleRisk covers where the platform came from and what it does, the Three Lines model describes how mature programs split GRC roles, and the framework tour maps the major frameworks to the features that support each.

Common pitfalls

A handful of failure patterns show up over and over. Most are discipline failures, not tooling failures, but the tooling can either help with them or quietly enable them.

• The "GRC team" treated as one role doing three jobs. A single analyst hired to "run GRC" gravitates to the discipline with the clearest deliverables, usually compliance, and the other two quietly atrophy. Governance becomes a folder of unread policy PDFs; the risk register becomes a spreadsheet that hasn't been touched since the last audit. One person can play all three roles, but not all at once. Schedule them.

• Compliance treated as the goal. A SOC 2 deadline appears, the team scrambles to assemble evidence, the report ships, and the program falls dormant until next year. Compliance is a byproduct of doing governance and risk well, not a destination. A program that only wakes up in audit season produces evidence that doesn't reflect reality the rest of the year, and a serious assessor spots it in the first hour.

• A risk register that nobody governs. Risks identified, never reviewed, never reported. Without a reporting line into a governance forum (a risk committee, a quarterly leadership review, something), the register becomes write-only and its value as a decision-making tool decays. See What is a Risk Register for the discipline of keeping one.

• Governance documented but not enforced. Policies on the wiki, with no consequence for breaking them and no review cadence checking. The classic version is a password policy that says "no shared accounts" while ops has been sharing one for two years. The fix isn't a stricter policy; it's an exception process and a control test that catches the gap. Policies without enforcement are worse than no policies — they make the program look mature on paper without producing any of the underlying behavior.

• Compliance evidence that doesn't reflect reality. The SOC 2 report says backups run weekly; the actual backup job has been failing silently for three months. The control description says "access reviews are performed quarterly"; the last review on file is from 2023. This is what auditors mean by a program that is "well-documented but not operating," and it's the fastest way to lose trust with a customer who reads the report carefully.

• Treating the three as a sequence rather than co-disciplines. "First we'll do governance, then risk, then compliance" is a project-plan view that breaks down on day one. The three feed each other in cycles: risk identification surfaces a control gap; the gap goes to governance for a policy decision; the policy creates a control; the control needs evidence; collecting it surfaces a new risk. There's no "done" state where governance is finished and risk takes over.

• The pre-audit GRC stand-up. A directive lands the quarter before the first audit: "stand up GRC." A spreadsheet appears, sixty risks get scraped from a vulnerability scanner, a policy template gets copy-pasted. Three weeks later the auditor opens the register and asks how often it's reviewed. The honest answer is "this is the first review." Maturity matters more to a serious assessor than the row count.

Related

• The GRC Program Lifecycle
• Introducing SimpleRisk
• The Three Lines of Defense
• A Practitioner's Tour of GRC Frameworks