Is your data governance policy too complex to follow?

Policies that nobody can read don't get followed. Score your data governance documents — policies, standards, procedures, SOPs, data sharing agreements — against six readability formulas and see exactly which sentences are dragging the score down.

Why governance policies fail readability

Data governance writing has a structural problem the rest of corporate writing largely doesn't: it inherits its sentence patterns from legal contracts. Three patterns repeat across almost every policy document in the wild:

1. Long subordinate clauses. "Where the data classification of an asset has been determined to warrant additional protective measures, in accordance with the criteria set forth in Section 3.2, the asset owner shall ensure that…" — 40+ words before the actual instruction.
2. Nominalisations that hide the actor. "Data classification will be performed" obscures who classifies, when, and how. Active voice with a named role ("Data stewards classify each asset within 30 days of ingestion") restores the actor and cuts syllables.
3. Unexplained internal jargon. DLP, RBAC, MDM, CMDB, controlled vocabulary, data lineage, glossary entitlement, retention disposition. Each is meaningful to a governance practitioner; each is opaque to the operational staff who actually have to follow the policy.

The result is documents that audit-defensibly say the right thing while operationally failing — written for the regulator, not the user.

What reading level should a governance policy target?

The single biggest mistake governance teams make is publishing a 14th-grade-level policy and expecting an 8th-grade-reading workforce to comply with it. A policy that can't be read is a policy that doesn't exist.

Which readability formulas matter most for governance writing

Gunning Fog Index is the strongest single signal for governance documents. Fog penalises the percentage of 3+ syllable words more aggressively than Flesch-Kincaid does — which is exactly the pattern that breaks governance writing. Classification, retention, disposition, provisioning, attestation, certification, remediation, escalation: every governance noun is multi-syllable.

SMOG is the second pull. SMOG was calibrated against 100% comprehension (not the 50–75% threshold most other formulas use) — appropriate when the cost of misunderstanding is a compliance failure. Use SMOG for the policies that govern your highest-sensitivity data assets.

Flesch-Kincaid remains the right general-purpose default and the right number to put on a governance dashboard. It's the score business stakeholders are most likely to recognise.

Run all three. The pattern between them tells you what to fix: high Fog with normal Flesch-Kincaid means vocabulary is the problem. High SMOG with normal Fog means specific complex words are concentrated in a few sentences. Use the sentence-level highlighting on the calculator to find those sentences.

Three high-leverage edits for governance writing

1. Replace nominalisations with verbs and named actors

Before: Data classification will be performed by the responsible data steward within thirty (30) calendar days of asset onboarding, with the outcome of such classification being recorded in the enterprise data catalog.

After: Data stewards classify each asset within 30 days of onboarding and record the classification in the data catalog.

Word count: 38 → 20. The named actor (data stewards) replaces the passive nominalisation. The instruction is now executable.

2. Split sentences at the conjunction

Any policy sentence over 25 words is almost always two policy sentences pretending to be one. The split point is usually a conjunction: "and," "where," "which," "provided that," "in accordance with."

Before: Where access to a restricted data set has been granted, in accordance with the entitlement criteria defined in the access management standard, the granting authority shall ensure that periodic recertification is performed not less than annually and that any anomalies identified during such recertification are escalated to the data owner.

After: Granting authorities recertify restricted-data access at least annually, following the criteria in the access management standard. They escalate any anomalies they find during recertification to the data owner.

Word count: 50 → 30 across two sentences. Each sentence makes one point.

3. Define jargon on first use, then prefer it consistently

Most governance policies fail at jargon in the opposite of the obvious way: they use seven different terms for the same concept ("data asset," "information asset," "data resource," "dataset," "data object," "information object," "managed data element") and use one term ("classification") to mean three different things across the same document.

Pick one term per concept. Define it once in a glossary or sidebar. Use it consistently. Readers spend their cognitive budget on the substance of the policy, not on figuring out whether two terms are synonyms.

A practical governance-document editing workflow

1. Paste the policy into the calculator. Note the consensus grade and which individual formulas are highest.
2. Open the sentence-level highlight panel. The red sentences are your edit list, in order of impact.
3. For each red sentence: apply the three edits above (replace nominalisations, split at conjunctions, swap jargon for explained terms).
4. Re-score. The consensus grade should drop by 1.5 to 3 points on a typical first pass.
5. Read the revised policy out loud. Anywhere you stumble is where a reader will stumble.
6. Send the revised draft to one person who has to follow the policy (not who wrote it). If they read it without flinching, you're done.

Most policies can drop from 13th grade to 10th grade in 30 minutes. The substantive precision usually improves alongside the readability — clear sentences are harder to write but easier to audit.

Who this matters for

• Data governance leads rewriting inherited policies for an operational audience.
• Compliance and risk teams trying to demonstrate that policies are actually communicable.
• Privacy officers drafting customer-facing notices that must meet GDPR/CCPA plain-language obligations.
• Information security teams writing acceptable-use, access-control, and incident-response policies that staff are expected to follow.
• MDM and data quality practitioners writing operational SOPs.
• Auditors evaluating whether a control narrative is itself audit-defensible.

Frequently asked questions