The seven building blocks of GRC — a walkthrough

A Teaching Lesson · Foundations of GRC

The Seven Building Blocks of GRC

What each one is, in plain language — and why an organization can't govern anything, least of all AI, without it. Built to teach from.

AudienceStudents & new practitioners

Running exampleA restaurant & an AI firm

Blocks7 concepts

PrereqsNone

Start here

First: what do the three letters mean?

GRC stands for Governance, Risk, and Compliance — three jobs every serious organization must do at once. They sound abstract, so anchor them:

Governance

Setting direction and deciding who is accountable. “Who is in charge, and by what rules?”

Risk

Understanding what could go wrong and how badly. “What are we worried about, and how much?”

Compliance

Proving you meet the rules that bind you. “Can we show we're following the law?”

Here's the key idea for the whole lesson: these three jobs are done using seven concrete things — frameworks, policies, controls, risks, mitigations, audit findings, and compliance mappings. Learn these seven and you can read any GRC system, in any industry, including one governing generative AI. They are the vocabulary of the discipline.

★ The one analogy we'll use throughout

Imagine you run a restaurant that has to pass a health inspection. You'll see that every abstract GRC term has an obvious, everyday twin in that kitchen — the health code, your house rules, the handwashing sink, the fear of food poisoning, the inspector's report. Keep the kitchen in mind and none of this stays abstract.

The external rulebook

Regulatory Frameworks

The laws, regulations, and standards you are required to obey.

Plain meaning

A framework is a body of rules imposed on you from the outside — by a government, a regulator, or an industry body. You don't get to negotiate them; you either comply or face consequences (fines, lawsuits, losing your licence).

In the kitchen

The national Health & Safety Code. Also the fire code, and the card-payment rules your terminal must follow. Rules written by someone else that you must live by to stay open.

Details to know

Each framework has a jurisdiction — the territory where it applies. This decides whether it even affects you: a US health law doesn't bind a European bakery. Frameworks also change over time, so each carries a last-updated date — following a stale version is itself a failure.

Why it matters

Frameworks are the “why” behind everything else. Every rule you set and every safeguard you build ultimately exists to satisfy some framework. Miss one that applies to you and no amount of internal effort protects you — you're breaking a law you didn't know you were under.

Real example

An EU financial firm is bound by GDPR (privacy), SOX (financial reporting), PCI DSS (card data) — and now, for its AI, three new ones: the EU AI Act, AICM, and AIEU. The AI frameworks arrived far more recently than the rest, which is exactly why most firms are behind on them.

Common misconception

“A framework and a policy are the same thing.” No — a framework is external (the law), a policy is internal (your response to the law). Confusing them is the single most common beginner mistake.

Ask the className two rulebooks your school or workplace must follow that nobody inside it invented. Who wrote them, and what happens if you ignore them?

Your own rules

Policies

The organization's own statements of intent — what you require of yourselves.

Plain meaning

A policy is an internal rule you write for yourself, usually to satisfy a framework or to prevent a risk. It says what must be true (“all staff wash hands”) but not how you'll make it true — that's the next block.

In the kitchen

Your house rules pinned by the door: “Wash hands on entry.” “Cook chicken to 75 °C.” “No phones at the prep station.” Rules you chose, to keep the health code happy and customers safe.

Details to know

A real policy always has an owner — a named senior person answerable for it (not “the company,” an actual role). It has an effective date and a review date, because rules must be re-approved periodically. And it has a status:

ActiveDraftUnder ReviewRetired

Only an Active policy has real authority. A draft is just a proposal.

Why it matters

Policies turn a vague intention (“be secure”) into a stated commitment someone owns. Without a policy, there's no mandate — nobody can be told to build a safeguard, and nobody can be held accountable when one is missing. Policy is where governance becomes real.

Real example

Our AI firm has 12 policies. Eleven are Active. The one that matters most — the AI Governance Policy — is stuck Under Review. Because it was never ratified, no one has the authority to demand AI safeguards. That one un-approved policy is the root of the firm's entire AI failure.

Common misconception

“We have a policy, so we're covered.” A policy is only a promise. If no mechanism enforces it and no evidence shows it's followed, it protects no one. A policy without controls (Block 3) is a poster on a wall.

Ask the classWhy might a company keep a policy in “Under Review” for a year? What is the quiet cost of never finishing it?

The safeguards

Controls

The actual mechanisms that make a policy real and reduce risk.

Plain meaning

If a policy says what must be true, a control is the concrete thing that makes it true. It's the safeguard you can point at, switch on, and test. Controls are the workhorses of GRC — most of the real effort lives here.

In the kitchen

The handwashing sink by the door. The thermometer in the fridge. The temperature log the cook fills in twice a day. Physical, checkable mechanisms that enforce the house rules.

Details to know

Controls come in four types by when they act:

Preventive — stops it happeningDetective — catches it happeningCorrective — fixes it afterCompensating — a backup when the ideal isn't possible

And crucially, a control has two separate health checks, not one:

• Implementation status — does it exist? Implemented Partially Planned Not Implemented
• Effectiveness — does it work? Proven by testing. Effective Partially Ineffective Not Assessed

Why it matters

Controls are where intent becomes protection. The two-status split is the deep lesson: a control can be built but never tested — so you cannot yet claim it works. “We installed a sink” and “the sink actually gets used correctly” are different facts. Auditors care about the second.

Real example

The firm's data-encryption control is Implemented + Effective, tested last month — mature. But all 12 of its AI controls (bias testing, human oversight, conformity assessment…) are Planned or Not Implemented, and not one is Effective. The firm knows how to build controls; it just hasn't pointed that skill at AI yet.

Common misconception

“Implemented means it works.” Not necessarily. Implemented means it exists; Effective means testing proved it works. A fire extinguisher bolted to the wall but never inspected is implemented and possibly useless.

Ask the classGive one preventive, one detective, and one corrective control for the risk “laptop gets stolen.” Which stops the harm, which spots it, which limits it?

What could go wrong

Risks

The potential harmful events — scored so you can rank and act on them.

Plain meaning

A risk is a future event that might happen and would hurt if it did. GRC doesn't try to eliminate all risk (impossible) — it tries to see risks clearly and decide which ones to act on first.

In the kitchen

“A customer gets food poisoning.” “A fire starts on the grill.” “We fail inspection and get shut down.” The bad outcomes you lie awake worrying about.

Details to know

To compare risks fairly, you score two dimensions, each 1–5, and multiply:

Likelihood × Impact = Risk Score

The score (1–25) sorts into levels:

Low 1–5Medium 6–11High 12–19Critical 20–25

Each risk also has a status — the decision you've made about it: Open Mitigated Accepted Transferred Closed — and a named owner.

Why it matters

Scoring is a forcing function. Two people who both call a risk “bad” might be far apart on how bad — saying “likelihood 4, impact 5” out loud settles the argument and, more importantly, forces leadership to confront a danger they were treating as routine. A number gets budget; a worry doesn't.

Real example

The firm's worst risk is “Deploying a high-risk AI system without the required assessment.” Likelihood 4 (it's on track to happen), Impact 5 (huge fines + real people harmed) = 20 = Critical — the only Critical on its whole register. That single number is what finally makes a launch decision a boardroom conversation.

Common misconception

“Our goal is zero risk.” No — zero risk means zero activity. The goal is informed risk: know what you're carrying, and consciously decide to reduce, accept, or avoid it.

Ask the classScore two risks for a school: “a student trips on a loose stair” vs. “a data breach leaks student records.” Which scores higher, and does that match your gut?

The plan of action

Risk Mitigations

The dated plan for reducing a specific risk — often by building a control.

Plain meaning

A mitigation is the “what we're going to do about it” attached to a risk. It connects a worry (Block 4) to an action or a control (Block 3), with a deadline. It's what turns a risk register from a list of fears into a project plan.

In the kitchen

For the food-poisoning risk: “Install a second handwashing sink by Friday.” “Retrain all cooks on the temperature log this month.” Specific moves, with owners and due dates.

Details to know

Every mitigation picks one of the four risk-treatment strategies — remember them as the four T's:

Avoid — don't do the risky thingMitigate — reduce it with a controlTransfer — insure / contract it awayAccept — consciously live with it

It also tracks status and dates: Planned In Progress Completed Overdue.

Why it matters

A risk you've logged but aren't treating is just a documented failure waiting to happen. Mitigations add accountability and time — a named owner and a due date. Watching mitigations slip to Overdue is often the earliest warning sign of a program in trouble.

Real example

Every mitigation tied to the firm's AI risks reads Planned or In Progress — never Completed. The intent to fix things exists on paper; the delivery is entirely outstanding. That gap between plan and done is the story of most struggling programs.

Common misconception

“Transferring a risk (e.g. buying insurance) makes it go away.” It moves the financial blow, not the event — and you usually can't transfer legal or regulatory responsibility. If your AI breaks the law, insurance won't make you compliant.

Ask the classFor “our website could be hacked,” write one mitigation using each of the four T's. Which feels most responsible, and why can't you always just Avoid?

The independent check

Audit Findings

An independent examiner's proof that a control does — or doesn't — work.

Plain meaning

An audit finding is a gap discovered by someone independent when they inspect a control. It's the reality check on all your confident claims — the moment “we think it works” meets “let's actually test it.”

In the kitchen

The health inspector's report: “Fridge running 3° too warm — fix within 14 days.” An outsider, checking your safeguards, writing down exactly what's wrong and by when it must be fixed.

Details to know

Each finding names the specific control that failed (findings are never vague), and carries:

• a severity: Critical High Medium Low Informational
• a status: Open In Remediation Closed Risk Accepted
• a remediation owner and a due date — a dated, owned commitment to fix it.

Why it matters

This is independence — the value is that the checker isn't the builder. A finding with an owner and a deadline is a commitment; without them it's just a complaint. The real worth of an audit isn't discovering the gap — it's the tracked promise to close it.

Real example

The firm's most serious finding: “No conformity assessment completed for any AI system despite the law taking effect.” Severity Critical, still Open. An independent voice confirming, in writing, the same danger the control data implied — which is much harder for leadership to ignore.

Common misconception

“Audits are about catching people out.” Good audit is about assurance — giving leadership trustworthy proof of what's actually working, so they can fix the real gaps before an outsider (or an attacker) finds them first.

Ask the classWhy should the person who built a safeguard not be the one who audits it? What might they be blind to?

The proof of compliance

Compliance Mappings

The crosswalk that proves “this safeguard satisfies that specific rule.”

Plain meaning

A compliance mapping is the link that connects a control to a specific requirement in a framework — and points to the evidence that proves it. It's literally how the “C” in GRC gets calculated: not by opinion, but by mapped, evidenced links.

In the kitchen

The line in your compliance binder that says: “Our fridge temperature log satisfies Health Code §4.2” — and clips the actual logbook behind it as proof. Rule ↔ safeguard ↔ evidence, in one entry.

Details to know

Each mapping records the control, the framework, the exact requirement reference (e.g. “Art. 14 — Human Oversight”), a status — Compliant Partially Non-Compliant Not Assessed — and the one field that decides everything: the evidence location, a pointer to the document that proves the claim.

Why it matters

Here's the hardest truth in GRC: compliance is not what you do — it's what you can prove. A safeguard that works perfectly but has no evidence attached counts, to an auditor or a regulator, as non-compliant. The evidence pointer is the difference between “trust me” and “here it is.”

Real example

The firm's traditional mappings (GDPR, card rules) point to real documents and read Compliant. Every one of its AI mappings reads Non-Compliant with the evidence field empty. Same organization — the difference between green and red is entirely whether there's a document to point at.

Common misconception

“If we're doing the right thing, we're compliant.” Doing it isn't enough — you must be able to show it on demand, tied to the exact rule. No evidence, no compliance, no matter how good your intentions.

Ask the classYou genuinely cook every chicken to 75 °C but never write it down. The inspector asks for proof. Are you compliant? Why is the answer uncomfortable?

Putting it together

One story, told in seven words

The blocks aren't a pile of definitions — they form a single sentence of accountability. Read it as a story about our restaurant:

The health code (framework) requires safe food, so we write a house rule (policy) to cook chicken through, enforced by a thermometer and log (control), because we fear a food-poisoning case (risk), which we're reducing by retraining the cooks this month (mitigation); the inspector's report (audit finding) flagged our fridge runs warm, and our compliance binder (mapping) shows the log satisfies Code §4.2, logbook attached as proof.

That single thread — external rule → internal rule → mechanism → worry → plan → independent check → documented proof — is the entire discipline. When you can follow it end to end for any one safeguard, you understand GRC. And it works identically whether the safeguard is a kitchen sink or a bias test on an AI model.

Teacher's quick reference

The vocabulary vault

Hand these to students as flashcards. Each set is a small, closed list — memorizing them is most of the battle.

Term set	The options	The idea in one line
Control types	Preventive · Detective · Corrective · Compensating	Classified by when the safeguard acts — before, during, after, or as a backup.
Control existence	Implemented · Partially · Planned · Not Implemented	Does the safeguard exist yet?
Control effectiveness	Effective · Partially · Ineffective · Not Assessed	Does it work? Proven only by testing.
Risk score	Likelihood (1–5) × Impact (1–5)	Turns a worry into a comparable number, 1–25.
Risk levels	Low · Medium · High · Critical	The score bucketed for priority.
Risk treatment (4 T's)	Avoid · Mitigate · Transfer · Accept	The four choices for any risk. There is no fifth.
Compliance status	Compliant · Partially · Non-Compliant · Not Assessed	Requirement met and evidenced — or not.
Finding severity	Critical · High · Medium · Low · Informational	How urgently a discovered gap must be fixed.

The five things students should leave able to say

A framework is a rule imposed on you; a policy is a rule you impose on yourself.
A control can exist without working — implemented and effective are two different facts.
A risk is scored (likelihood × impact) so it can be ranked and funded, not just feared.
Every risk gets one of exactly four treatments: avoid, mitigate, transfer, accept.
Compliance is what you can prove — no evidence means non-compliant, however well you're doing.

The Seven Building Blocks of GRC — a foundations lesson for teaching governance, risk & compliance from first principles. Companion to the practitioner course “GRC for Generative AI.” Examples draw on a synthetic financial-services dataset; the restaurant is imaginary, the lesson is not.