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.

Last updated 8 October 2026

Why governance policies fail readability

Data governance writing often borrows its sentence patterns from legal contracts. Three patterns are common:

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…" — 25 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?

These bands are our working suggestions. No law or standard sets them. A policy that staff cannot read will not be followed.

Which readability formulas matter most for governance writing

Gunning Fog Index is a useful signal for governance documents. Fog combines sentence length with the share of words of three or more syllables, and many governance nouns are long: classification, retention, disposition, provisioning, attestation, certification, remediation, escalation.

SMOG is a stricter check. SMOG is set to complete comprehension, which suits text where a misunderstanding is costly. Use it for the policies that govern your most sensitive data.

Flesch-Kincaid is a sensible general-purpose default. It is one of the two scores Microsoft Word shows, so colleagues can check it in Word themselves.

Run all three. Then use the sentence-level highlighting on the calculator to find the sentences to fix.

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: 31 → 18. The named actor (data stewards) replaces the passive nominalisation. The instruction is now executable.

2. Split sentences at the conjunction

A policy sentence over 25 words can usually be split in two. 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 → 28 across two sentences. Each sentence makes one point.

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

A common jargon problem is the reverse of the obvious one: several terms for the same concept ("data asset," "information asset," "data resource," "dataset") and one term ("classification") used for different things in 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. Look at the sentence highlights. The red sentences are your edit list.
3. For each red sentence: apply the three edits above (replace nominalisations, split at conjunctions, swap jargon for explained terms).
4. Re-score and compare the consensus grade with your target.
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.

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 Article 12's "clear and plain language" rule.
• 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