Working Checklists for the NIST AI RMF: A Practical Tips Series: Govern

GOVERN

Part 1 of 4 — GOVERN, MAP, MEASURE, MANAGE

GOVERN is the function most organizations get wrong in a specific way: they write it down and consider it done. NIST didn’t design GOVERN as a documentation requirement. It’s the only function of the four that’s explicitly meant to run underneath the other three. It’s supposed to be the thing that makes MAP, MEASURE, and MANAGE actually happen instead of just existing as diagrams in a slide deck.

That distinction matters because it’s exactly where compliance theater lives. A policy that nobody enforces, a risk committee that meets and produces minutes but no decisions, an AI ethics statement with no mechanism attached to it. All of that satisfies “do you have GOVERN documentation” and none of it satisfies “does GOVERN function.” This checklist is built around the second question.

I’ve grouped it by NIST’s six GOVERN categories. For each, I’m giving you the operational test.

GOVERN 1: Policies, Processes, and Practices Are in Place and Actually Implemented

You can name the specific AI-relevant legal and regulatory obligations that apply to your organization, updated on a cadence
Your AI risk policy states what happens when someone wants an exception and that path has been used at least once, by someone other than the person who wrote the policy
Risk management documentation is legible to someone who didn’t write it
There’s a defined review cadence for AI policies (not “as needed”), and the last review changed something
You have a documented decommissioning process for AI systems, and it’s been exercised

Theater vs. real:Theater is a policy document with a version number that’s never incremented. Real is a policy with a changelog that shows it responding to something.

GOVERN 2: Accountability Structures Are Clear

There’s a named individual accountable for AI risk decisions. If you asked ten people in the company “who owns this,” would you get one answer?
Roles and escalation paths are documented somewhere people can find them, not buried in a wiki page nobody has opened since onboarding
Training exists for the roles that touch AI risk decisions, and it’s role-specific
Executive leadership has taken on explicit responsibility for AI risk outcomes and this shows up in things like board reporting, not just an org chart line

Theater vs. real:Theater is an “AI governance committee” that exists on paper with no decision rights. Real is knowing, without checking, who gets paged when something goes wrong.

GOVERN 3: Diverse Perspectives Are Built Into Decision-Making

Use case review or intake includes people outside the team building the system
There’s a mechanism for dissent to reach a decision-maker before launch, not after
Workforce-impact risks (displacement, deskilling, monitoring) are explicitly considered in AI deployment decisions, not treated as out of scope because “that’s HR’s problem”

Theater vs. real:Theater is a diversity statement in the AI policy. Real is a use case that got killed or redesigned because someone in the review caught something the builders didn’t.

GOVERN 4: Organizational Culture Treats Risk Management as Real Work

People raising AI risk concerns get taken seriously. You’d know this by looking at what happened the last time someone did it, not by asking if they’d feel comfortable doing it
Risk and benefit tradeoffs for AI systems are documented in a form someone could use to prioritize response
There’s an active mechanism for surfacing emergent risk
Critical thinking about AI outputs is a stated expectation, not an assumption. If your acceptable use policy doesn’t say “don’t blindly trust the output,” it’s assuming a maturity level you probably don’t have organization-wide

Theater vs. real:Theater is a risk register that hasn’t been updated since the ISO audit that required it. Real is a risk register with drift you’re actively fighting because you know what drift costs you.

GOVERN 5: External and Internal Stakeholders Can Actually Feed Back In

There’s a defined channel for people affected by AI systems to raise concerns, and it routes to someone with authority to act
Stakeholders (customers, regulators, affected employees) receive information about AI system risks in a form they can use (not a privacy notice footnote)
Feedback received through these channels has changed something in the last two quarters

Theater vs. real:Theater is a feedback form that goes to an inbox nobody monitors. Real is a feedback loop with a documented example of it closing.

GOVERN 6: Third-Party AI and Data Risk Is Actually Managed

You have a tiered vendor risk framework for AI tools and data sources and not a single generic questionnaire applied regardless of risk level
Contracts with AI vendors address what happens when the vendor’s model changes, degrades, or becomes unavailable
There’s a contingency process for third-party AI failure that’s been tested, or at least walked through, not just written into a BC/DR appendix
You know, right now, which of your AI vendors would materially disrupt your operations if they disappeared tomorrow and you have a plan for at least the top few

Theater vs. real:Theater is a vendor risk questionnaire that gets sent, filed, and never looked at again. Real is a VRA that changed a contract term or killed a deal.

The test that cuts across all six

If you strip away the categories, GOVERN really reduces to one question, asked six different ways: when something goes wrong, does the structure you’ve built catch it, or does it just explain afterward why it wasn’t caught?

Most organizations can produce the documentation. Fewer can produce the incident where the documentation did something. That’s the gap this checklist is trying to help you close and it’s the gap an auditor, a regulator, or a customer’s security team will eventually go looking for, whether you’ve closed it or not.

Next in this series: MAP — the checklist for getting AI risk context right before a system ever reaches production.