In the last unit you settled who gets to decide. But a decision that lives only in someone's head, or in the fading memory of a meeting, quietly disappears. The way governance makes a decision outlast the room is by writing it down, and not just anywhere: in the right kind of document. This unit gives you the small vocabulary that keeps those documents from blurring together, then shows you how to turn a fuzzy good intention into something a team can actually follow.

When leaders say "we need a policy for this," they often mean five different things at once, and that confusion is where governance documents go to die. The Governance Document Hierarchy sorts them into a clean ladder. A policy states what must be true ("customer data must be accurate"). A standard defines the measurable requirements that prove it ("every customer record has a valid email, checked monthly"). A procedure explains the steps someone follows to meet that standard. A guideline recommends good practice without mandating it. And a control provides the evidence that the requirement is actually being met, like a monthly check that flags blank fields.

Think of it like a household rule. The policy is "the kitchen stays clean." The standard is "no dishes left in the sink overnight." The procedure is how you load the dishwasher. The guideline is a tip about which cycle works best. The control is the person who glances at the sink before bed. As a Data Governance Analyst, most of your daily writing lives in the top two rungs: naming what must be true, then making it testable.

Here's the move that matters most. A principle like "our data should be trustworthy" feels complete, but it commits no one to anything. Your job is to translate it down one rung, from a policy statement into a standard with measurable requirements and a named owner. The test is simple: could a colleague look at a record and say "met" or "not met" without arguing? If yes, you have a standard. If it sparks debate, you still have an aspiration.

• Natalie: Leadership signed off on "our customer data should be accurate." So we're covered, right?
• Chris: That's a policy, not a standard. It says what must be true, but nobody can test it. What does "accurate" even mean on a Tuesday?
• Natalie: Fair point. So every customer record has a valid email and a verified phone number, reviewed monthly, owned by the customer-domain lead?
• Chris: Now I can check that. Met or not met, with a name attached. That's a standard.

Notice that Chris didn't reject the principle, he just pushed it down a rung until it became checkable.

For now, keep your standards focused on the basics: definitions, ownership, glossary upkeep, and simple operating expectations. Deeper standards for access, retention, sensitivity, and data quality build on frameworks you'll meet in later courses, so resist the urge to bake those in yet.

Before a standard goes out, run it through four quick checks. First, clarity: is the wording unambiguous, or could two reasonable people read it differently? Second, testability: is there a concrete way to verify met or not met? Third, ownership: is one named person accountable for it, the same single-owner discipline you used with RACI? And fourth, exception handling: when the rule genuinely can't be met, is there a defined path to request an exception, rather than people quietly ignoring it?

A standard that fails any of these gets dropped the moment teams disagree, because there's no shared way to settle the argument. The phrase "keep data accurate" fails three at once: it's vague, untestable, and ownerless. The version Natalie landed on passes all four. That gap is exactly what separates a document people follow from a poster nobody reads.

The one thing to carry out of this unit: a principle tells people what must be true, but only a clear, testable, owned, exception-handled standard tells them how you'll know. Next you'll sort real examples into policy, standard, procedure, guideline, and control to lock in the ladder, then draft a testable standard of your own, and finally coach a colleague through fixing a vague one out loud. Start with one habit: whenever someone hands you a "policy," ask "how would we test that?" and watch how fast the real work appears.