What Is GRC, Really? Governance, Risk, and Compliance from the Primary Sources

Ask five security professionals what GRC means and you'll get five different answers: "paperwork," "audits," "the people who slow us down," "policy writing," or — from vendors — "a software category." All five answers are wrong, or at least badly incomplete. So before this series goes anywhere, this first post does one job: define governance, risk, and compliance precisely, using the sources that actually get to define them — ISO, NIST, and the body that coined the term in the first place.

Where the term comes from

The acronym GRC was popularized by OCEG (originally the "Open Compliance and Ethics Group") in the early 2000s. OCEG's formal definition is worth quoting in spirit: GRC is the integrated capability that enables an organization to reliably achieve objectives, address uncertainty, and act with integrity. Read that again, because each clause maps to one letter:

• Reliably achieve objectives → Governance

• Address uncertainty → Risk management

• Act with integrity → Compliance

Notice what's not in that definition: audits, spreadsheets, policies, or tooling. Those are instruments. GRC itself is an organizational capability — and importantly, an integrated one. The whole reason the acronym exists is that organizations historically ran governance, risk, and compliance as three disconnected silos, duplicating work and contradicting each other.

Governance: who decides, and how

The formal definitions

ISO/IEC 27014 (Governance of information security) describes governance as the system by which an organization's information security activities are directed and controlled. Direction flows down (leadership sets objectives, appetite, and policy); evaluation and monitoring flow up (leadership receives assurance that direction is being followed).

NIST made governance dramatically more prominent in 2024: NIST CSF 2.0 added GOVERN (GV) as a sixth function, sitting at the center of the other five (Identify, Protect, Detect, Respond, Recover). In CSF 2.0's words, the Govern function establishes and monitors the organization's cybersecurity strategy, expectations, and policy. Its categories tell you exactly what governance consists of in practice:

• Organizational Context (GV.OC) — understanding the mission, stakeholders, and legal/regulatory environment the security program serves

• Risk Management Strategy (GV.RM) — risk appetite, risk tolerance, and how risk decisions get made

• Roles, Responsibilities, and Authorities (GV.RR) — who is accountable for what

• Policy (GV.PO) — establishing and communicating organizational cybersecurity policy

• Oversight (GV.OV) — reviewing whether the strategy is actually working

• Cybersecurity Supply Chain Risk Management (GV.SC) — governing third-party risk

The plain-language version

Governance answers three questions: Who has the authority to make security decisions? What are those decisions based on? And how does leadership verify the decisions are being carried out? If your organization can't answer those three questions, it doesn't have a governance problem — it has no governance at all, just individual people doing their best.

A concrete example: an analyst can't decide alone whether the company accepts the risk of leaving a legacy server unpatched. That's a risk acceptance decision, and governance determines who is entitled to make it (an IT manager? the CISO? the board?), against what criteria (documented risk appetite), and how it's recorded (a risk register with sign-off). Governance is the machinery that makes that a decision rather than an accident.

The instruments of governance

In practice, governance materializes as a small set of artifacts and structures: a security policy hierarchy (policies → standards → procedures — the subject of the next topic in this path), defined roles (CISO, security steering committee, data owners), a risk appetite statement, and a management review cadence. ISO/IEC 27001 hard-codes this: Clause 5 (Leadership) requires top management to establish policy and assign roles, and Clause 9.3 (Management Review) requires leadership to periodically review the security management system's performance. Governance is not optional decoration in ISO 27001 — it's a certifiable requirement.

Risk: uncertainty, made manageable

The formal definitions

ISO 31000, the umbrella risk management standard, defines risk with elegant brevity: the effect of uncertainty on objectives. Note that this definition is neutral — the effect can be negative or positive. In security we almost always work with the negative side, and for that, NIST SP 800-30 Rev. 1 gives the operational definition: information security risk is a function of (1) the likelihood that a threat source exercises a vulnerability, and (2) the resulting impact on the organization.

That single sentence contains the four load-bearing concepts of all security risk work:

• Asset — something of value to the organization (data, systems, reputation, availability of service)

• Threat — a potential source of harm (a ransomware crew, a careless employee, a datacenter fire)

• Vulnerability — a weakness the threat can exploit (an unpatched service, a missing process, an over-privileged account)

• Impact — what the organization loses if it happens

No threat without a vulnerability = no risk. A vulnerability with no threat that can reach it = no risk. This is why "we have 4,000 vulnerabilities" is not a risk statement — it's an inventory. Risk only exists at the intersection.

Risk management as a cycle

ISO 31000 and NIST SP 800-37 (the Risk Management Framework) both describe risk management as a continuous cycle rather than a one-time assessment. Compressed, the cycle is: establish context → identify risks → analyze them → evaluate against appetite → treat → monitor → repeat. The four canonical treatment options appear in every standard, sometimes under different names:

1. Mitigate (reduce) — apply controls to lower likelihood or impact

2. Transfer (share) — insurance, outsourcing, contractual shifting

3. Avoid — stop doing the risky activity

4. Accept — a deliberate, documented, authorized decision to live with it

The word deliberate matters. Every organization accepts risk constantly; mature ones do it on purpose, in writing, at the right level of authority. That's the bridge back to governance.

Why security teams get risk wrong

Security practitioners tend to treat risk as a technical property ("this CVE is critical"). Risk is a business property: the same vulnerability carries wildly different risk on an internet-facing trading platform than on an isolated test box. CVSS scores measure severity of a weakness; risk requires adding the organization's context — asset value, exposure, existing controls, and business impact. This distinction — severity vs. risk — will come back repeatedly in this series, especially in the risk management and vulnerability management topics.

Compliance: obligations, demonstrated

The formal definition

ISO's management-system vocabulary defines compliance/conformity as the fulfilment of a requirement — and the important move is understanding where requirements come from. Broadly, three sources:

1. Legal and regulatory obligations — laws you have no choice about: GDPR for personal data of people in the EU, NIS2 for essential and important entities in EU member states, DORA for EU financial entities, sectoral laws elsewhere.

2. Contractual obligations — requirements you agreed to: PCI DSS (a contractual standard flowing from card brands through banks to merchants), customer security clauses, SLAs.

3. Voluntary commitments — standards you chose to adopt and possibly certify against: ISO/IEC 27001, SOC 2 attestation, industry codes of conduct.

Compliance work, then, is a three-step discipline: identify which obligations apply to you (harder than it sounds — scoping questions like "does NIS2 apply to us?" are genuine legal analysis), implement what they require, and — the step outsiders forget — demonstrate it. Regulators, auditors, and customers do not accept "trust us." Compliance without evidence is a claim, not a fact. This is why so much of GRC work product is evidence: logs, records, signed approvals, audit trails, training completions, review minutes.

Compliant ≠ secure

The most important critical-thinking point in this entire post: compliance and security are correlated but not identical. An organization can satisfy every checklist item and still be breachable (controls implemented on paper, not in operation), and an organization can be highly secure while failing an audit (excellent engineering, zero documentation, no demonstrable process). Standards themselves acknowledge this — ISO 27001 requires controls to be selected from risk assessment results, not applied blindly, precisely so the management system tracks real risk rather than a generic checklist. When compliance and security disagree in an organization, it's usually a symptom that governance has failed to connect them.

How the three interlock

Here's the integration OCEG had in mind, stated as a chain of dependencies:

Governance sets objectives and risk appetite and assigns authority. Risk management uses that appetite to decide which threats matter and which controls are worth their cost. Compliance overlays the non-negotiable external obligations and proves — to regulators, customers, and leadership itself — that the whole system is operating.

Remove any link and the others degrade. Risk management without governance produces risk registers nobody acts on, because no one has the authority to accept or fund treatment. Compliance without risk management produces checkbox security — controls chosen because an auditor asked, not because a threat exists. Governance without compliance leaves the organization blind to legal obligations until a regulator finds them first.

And beneath all three sits security operations — the detection, response, hardening, and engineering work — as the layer where governance's decisions, risk's priorities, and compliance's obligations become running controls. GRC is not a different world from operations; it's the reason operations is configured the way it is.

What's next in the path

The next post in this series maps the landscape that this post kept name-dropping: what exactly ISO 27001, NIST CSF, CIS Controls, SOC 2, GDPR, NIS2, DORA, and PCI DSS are, how they differ in legal force and purpose, and how to tell a law from a framework from a certifiable standard from an attestation — because confusing those categories is the single most common beginner mistake in GRC.

Sources

• OCEG — GRC Capability Model (the origin of the integrated GRC definition)

• NIST Cybersecurity Framework (CSF) 2.0, February 2024 — the GOVERN function and its categories

• NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments (risk definition and model)

• NIST SP 800-37 Rev. 2 — Risk Management Framework

• ISO 31000:2018 — Risk management: Guidelines (risk definition, treatment options)

• ISO/IEC 27014 — Governance of information security

• ISO/IEC 27001:2022 — Clauses 5 (Leadership), 6 (Planning), 9.3 (Management review)