intellimetrics Learning
Zero Trust Implementation Module 4 · Applications and Data

Data as a Policy Input

Last reviewed

Intermediate

What you'll learn

~15 min
  • Build a label taxonomy small enough to use and wire auto-labeling to it
  • Connect data sensitivity to access decisions - the pillar's actual Zero Trust move
  • Sequence DLP from audit to block without triggering the business revolt

The pillar that got a forcing function

Data has always been the least mature Zero Trust pillar — everyone agrees it matters, nobody’s labels survive contact with real users. Then AI assistants arrived and did something accidental and clarifying: they made oversharing instantly visible. The copilot that cheerfully summarizes a salary file for anyone who asks didn’t create the permission problem — that file was always readable by half the org — it surfaced it, at chat speed. Every 2026 data-pillar program is riding that forcing function, and yours should too: “make the AI rollout safe” gets budget that “fix file permissions” never did.

Labels: the taxonomy that survives is small

The data pillar’s unit of policy is the sensitivity label — stamped on the document, traveling with it, machine-readable by every downstream control. The design rule learned by every failed rollout: four or five labels, not fifteen. A taxonomy people can hold in their head gets applied; one that needs a decision tree gets ignored, and unlabeled data is policy-invisible data.

Public          - the website, the outage map
Internal        - default for org content; the do-no-harm tier
Confidential    - customer PII, financials, most of the crown jewels
Restricted      - regulator case files, credentials, safety-critical OT docs

Humans mislabel and forget, so auto-labeling carries the volume: pattern-driven service-side rules stamp the obvious classes (account numbers, SSNs, credential material) and default-label inheritance covers repositories at rest — pre-AI hygiene for the mountains of existing content the assistants are about to index. Humans adjust edge cases; machines do the bulk. Meridian’s lake makes it easier than most estates: the Cloud Modernization data-contract discipline means datasets already have owners and dictionaries — the label is one more column in a governed catalog, not a greenfield crusade.

The Zero Trust move: labels drive decisions

A label that only colors a footer is decoration. The pillar earns its place in this training when sensitivity becomes a signal into the PDP — closing the loop with everything you’ve built:

Label            × Identity/device signal        => Decision
Confidential     × unmanaged device (CA08)       => browser-only, no download
Restricted       × any session                   => phishing-resistant step-up (2.2)
Restricted-app   × session age                   => re-evaluation ceiling: hourly
                                                    sign-in frequency (4.3 uses this)
Restricted       × elevated insider-risk level   => block external share + alert
any              × AI assistant context          => assistant honors label ACLs;
                                                    provenance-untrusted content
                                                    (4.1) never joins the prompt

That third row is adaptive protection — the newest pattern in the set: an insider-risk engine scores behavior, and the score swaps the user between DLP/access policy tiers dynamically. A user exhibiting exfil-shaped behavior gets the strict policy set automatically; everyone else keeps frictionless defaults. That’s tenet 4 (dynamic policy) reaching the data pillar — the same closed-loop shape as Lesson 3.1, with risk flowing from behavior instead of endpoint telemetry.

DLP without the revolt

Data-loss-prevention controls enforce the labels at the exits (mail, upload, USB, print). The rollout discipline is the module’s recurring one, because DLP block-mode on day one is the classic business revolt — legitimate workflows break loudly, executives escalate, and the program retreats to audit mode permanently, which is worse than sequencing honestly:

1. AUDIT      - watch flows per label/exit pair; find the legitimate-but-
                noncompliant workflows (there are always some)
2. FIX PATHS  - give those workflows sanctioned routes BEFORE blocking the
                unsanctioned ones (secure share links replace the vendor
                email attachments; Lesson 4.1's washroom handles inbound)
3. NOTIFY     - warn-and-continue with a justification prompt; the data
                tells you what block-mode will cost
4. BLOCK      - per label-tier, crown jewels first, with the exception
                register (owner + expiry) for the stragglers

Your artifact:

Design the data-pillar rollout: (1) the 4-label taxonomy with one-line
definitions and 3 examples each; (2) auto-label rules per label - patterns,
repository defaults, inheritance; (3) the label × signal decision table wired
to our CA baseline policy names; (4) the DLP audit→block sequence per exit
channel with the metrics that gate each promotion; (5) the AI-assistant
clause: which labels the assistants may index, and how provenance-untrusted
content is excluded from context. Assume the label catalog can piggyback on
our existing data-contract dictionary.
KNOWLEDGE CHECK

Meridian's copilot pilot is a hit — until someone asks it to 'summarize everything about substation access codes' and it obliges, quoting a Restricted operations doc stored in a broadly-shared team site. The knee-jerk proposals: ban the copilot, or delete the document. What does the data pillar actually prescribe?

Key takeaway

Four labels people can remember, auto-labeling carrying the volume, and the labels wired into the PDP so sensitivity changes decisions — download rules, step-ups, adaptive tiers, and what the AI assistants may index. Sequence DLP audit→fix→notify→block, and thank the copilot for the budget: it turned invisible oversharing into a demo. One question left in this module: what keeps a session honest after the decision.

Search lessons