The Seven Building Blocks of GRC

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).

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.

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.

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 (“every high-risk model decision is reviewed by a person”) but not how you'll make it true — that's the next block.

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:

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

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.

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.

Controls come in four types by when they act:

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

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.

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.

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

Likelihood × Impact = Risk Score

The score (1–25) sorts into levels:

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

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.

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.

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

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

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.

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.”

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.

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.

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.

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.

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.