Zero Trust Data Pillar Guide: Making Every Access Decision Data Aware

Most zero trust programmes verify the user, the device and the network path, then hand over the data with no further decision, so the asset attackers actually want is the one pillar with the weakest policy. The data pillar asks organisations to know what data they hold, describe it in labels that machines can read, and use those labels, together with identity and device signals, to decide access, encryption and monitoring for each request. This guide explains what CISA, the NSA, the DoD and OMB expect from the data pillar, how classification becomes a policy input, how to place decision and enforcement points at the data layer, how encryption and key management act as access control, and how to measure progress. It goes deeper than the overview in the CISA Zero Trust Maturity Model Guide and is written for security architects, data security leads and zero trust programme owners.

Key takeaways

• Labels are the policy language. The NSA describes granular attributes in data tags as what makes access control machine enforceable; without consistent labels, data aware zero trust policy has nothing to evaluate.
• Decide at the data, not only at the door. Check data attributes against subject and device attributes at more than one policy decision point, so a valid session to an application does not imply access to every record behind it.
• Encryption is an access control only if key use is controlled and logged. OMB M-22-09 requires a trustworthy log of decryption attempts kept by a system separate from the application, because encryption at rest does not stop a compromised component that is allowed to decrypt.
• Automate in report only mode first. Both OMB and the NSA advise starting categorisation and DLP in monitor or report only mode, tuning accuracy, then enforcing.
• Non-human identities read most of the data. Service accounts, pipelines and AI agents need the same time limited, least privilege, logged access to data as people, or they become the path around every data control.

What the data pillar asks for

CISA's Zero Trust Maturity Model version 2.0 scopes the pillar to all structured and unstructured files, fragments and metadata, including backups, wherever they sit: on devices, in applications and on networks. It defines five functions and three cross-cutting capabilities, each across Traditional, Initial, Advanced and Optimal stages.

The cross-cutting capabilities move from manual visibility to predictive analytics, from ad hoc lifecycle processes to automation as far as possible, and from ad hoc governance to unified, dynamically enforced lifecycle policy. At the Advanced stage of Data Access, CISA names the factors a decision should weigh: identity, device risk, application and data category. That sentence is the bridge between the data pillar and the rest of the model.

How the main frameworks frame the pillar

For the wider context of each, see the DoD Zero Trust Strategy and Reference Architecture Guide, the OMB M-22-09 Federal Zero Trust Strategy Guide and the NIST SP 800-207 Zero Trust Architecture Guide.

Classification as a policy input

A classification scheme written for humans ("Confidential: handle with care") is not yet a zero trust control. It becomes one when the label is stored as metadata the enforcement point can read, is consistent across stores, and maps to a defined set of permitted operations. The NSA recommends maintaining an enterprise catalogue of metadata, governance policies and usage patterns (the catalogue does not hold the data itself), identifying data owners, and prioritising security and mission critical data on high value assets before moving from manual to automated tagging.

• Keep the scheme small: three to five sensitivity levels plus a few handling attributes (personal data, regulated data, export controlled, legal hold) are easier to enforce than a long taxonomy. See the Data Classification Guide.
• Separate sensitivity from handling: a sensitivity label drives encryption and sharing defaults; handling attributes drive retention, residency and who may process the data.
• Accuracy before automation: OMB M-22-09 notes that early automation can use simple scripts or regular expressions, but warns that a pattern such as "any nine digits" for a Social Security number is unlikely to be reliably accurate. Measure precision before a label drives a block.
• Find mislabelled data: at advanced maturity the NSA expects tooling that finds improperly tagged sensitive data and alerts or quarantines it. See the Data Security Posture Management (DSPM) guide.

Making access decisions on data

NIST SP 800-207 separates the policy decision point (PDP), which evaluates a request, from the policy enforcement point (PEP), which allows or blocks it. In most deployments the PEP sits in front of the application. The data pillar adds enforcement at the data layer: the file service, the database proxy, the object store policy, the rights management client and the DLP engine. The NSA advises checking attributes at multiple policy decision points rather than once at sign-in.

NIST SP 800-162 defines attribute based access control (ABAC) as authorising an operation by evaluating subject, object, operation and environment attributes against policy. The NSA lists three workable models: RBAC (access by organisational role), PBAC (decisions from attributes set by policy rules) and ABAC (identity attributes matched to data object attributes). See the Authorisation Models Guide.

Decision guidance: use RBAC for well bounded applications with stable roles; it is simplest to review. Add ABAC conditions where the same role must see different records by label, region or project, which is the common case for shared repositories and data platforms. Reserve fully dynamic, risk adaptive decisions for the highest value data, because every additional attribute is another feed that must be accurate and available or access fails. Small organisations can reach most of the value with labels that drive sharing restrictions and encryption in their collaboration suite, plus conditional access requiring a compliant device for labelled content. Large organisations need a central policy definition that several enforcement points consume, otherwise each store drifts into its own rule set, which is the segmented governance CISA places at the Initial stage.

Encryption, keys and rights management as access control

• Audit decryption, not only storage: OMB M-22-09 points out that encryption at rest protects copied data but not access by a compromised component that is authorised to decrypt. It requires a trustworthy log of decryption attempts from key management tools, kept by a system separate from the application, and at advanced maturity correlation with other events to spot unusual database access.
• Least privilege for keys: CISA's Optimal stage applies least privilege to enterprise key management. Separate key administrators from data administrators and grant decrypt rights per workload, not per environment. See the Cryptographic Key Management Guide.
• Tag driven encryption: the NSA recommends encryption driven by tags, so a document labelled at a given level is encrypted with the matching policy wherever it is stored.
• Rights management when data leaves: where storage encryption cannot follow the data, digital rights management can block forwarding, editing, saving or printing. See the Information Rights Management and Persistent File Protection Guide.
• Key location: keys may be customer managed or provider managed under M-22-09; the control that matters is the independent audit trail. See the BYOK, HYOK and External Key Management Guide for when external keys are worth the operational cost.

Monitoring, DLP and availability

The NSA describes data monitoring as making data observable through metadata that tracks access, sharing, transformation and use, fed to the SIEM, then integrating DLP, rights management and user and entity behaviour analytics at advanced maturity. Its DLP advice is specific: place DLP at enforcement points throughout the architecture, not only at the perimeter; baseline normal data use before turning on prevention; identify sensitive content with key terms, fingerprints, pattern matching and exact file matching; start in monitor or learning mode, tune, then block; and keep a data recovery plan for when DLP fails. Pasting sensitive data into an AI tool is one of the insider examples it gives. See the Data Loss Prevention (DLP) Guide.

Availability is part of the pillar too: CISA moves from on-premises stores with some off-site backups to redundant, highly available stores with access to historical data. Backups are in scope of the pillar's inventory and labelling, so a backup copy must carry the same access rules as the source. See the Backup Identity Isolation Guide.

Where identity fits

The data pillar is where human and non-human access meet. ETL jobs, reporting service accounts, integration tokens and AI agents often hold broad, standing read access to entire stores, because they were granted at the database or bucket level when the project started. Apply the same rules as for people: an owner and purpose attribute on every workload identity, access scoped to the labels the workload needs, short lived credentials, decrypt rights only where required, and logs that name the workload rather than a shared account. CISA's Data Access Advanced stage asks for time limited controls where applicable, which for workloads means federated, short lived tokens instead of static keys. See the Data Access Governance Guide and the Zero Trust Identity Guide.

Implementation roadmap

1. Scope (months 0 to 3): pick the three to five data domains that matter most, name owners, and inventory where they live, including backups, exports and analytics copies. Record which identities, human and non-human, can read each.
2. Label (months 2 to 6): publish the label scheme, apply default labels to new content in priority stores, and run automated classification in report only mode to measure accuracy.
3. Encrypt and audit keys (months 3 to 9): confirm encryption in transit everywhere and at rest for priority stores; route decryption through a key service whose logs land in the SIEM, separate from the application.
4. Decide on data (months 6 to 12): add label conditions to access policy for the priority stores: block external sharing of the top label, require a compliant device for download, restrict workload identities to the labels they need. Pilot with one business unit and keep the previous policy ready to restore.
5. Monitor then prevent (months 6 to 18): run DLP in monitor mode at endpoint, email, collaboration and cloud enforcement points; baseline; move the highest confidence rules to blocking.
6. Automate and expand (year 2 onwards): automate labelling and remediation of mislabelled data, extend to more stores, add rights management for data that leaves, and move towards just in time access for sensitive data.

Roll back by returning a policy to report only, not by deleting it, so you keep the evidence of what it would have blocked.

Detection and measurement

• Log sources: data store access logs (object, file, database), key service decrypt events, label changes and downgrades, external sharing events, DLP matches and overrides, and rights management usage.
• High value alerts: bulk reads or decrypts by a workload identity outside its baseline, label downgrades followed by external sharing, access to the top label from a non-compliant device, and decrypt calls from an unexpected service.
• ATT&CK coverage: T1530 Data from Cloud Storage, T1213 Data from Information Repositories and T1567 Exfiltration Over Web Service are the techniques these signals detect most directly.

Framework mapping

Common failure patterns

• Labels with no consumer. Content is labelled but no access policy, DLP rule or encryption setting reads the label, so the programme reports coverage without changing risk.
• Zero trust stops at the application. Users pass strong authentication and device checks, then the application's service account reads the whole database. The NSA's worked example is a credit reporting agency breach in which stolen credentials gave access to 51 databases over 76 days.
• Encryption counted as access control. Storage is encrypted, but every component that can read it can also decrypt it, and decrypt events are not logged anywhere independent.
• Blocking before baselining. DLP goes straight to prevention, breaks workflows, and is rolled back to monitor only permanently.
• Copies outside the model. Analytics extracts, test data and backups carry no labels and sit outside the policies that protect the source.
• Workloads ignored. Human access is reviewed quarterly while pipelines and AI agents keep standing, store level access with long lived keys.

Practitioner checklist

• Name the priority data domains, their owners and every store, export and backup that holds them.
• Publish a short label scheme with sensitivity levels and handling attributes, stored as machine readable metadata.
• Run automated classification in report only mode and measure accuracy before any label drives a block.
• Add label conditions to access policy for priority stores, including for workload identities.
• Require a compliant device for downloading or syncing top label content.
• Route decryption through a key service whose logs are kept outside the application and sent to the SIEM.
• Deploy DLP at endpoint, email, collaboration and cloud enforcement points in monitor mode, then block high confidence rules.
• Apply rights management to the top label where data leaves your systems.
• Give every workload identity an owner, a purpose and label scoped, short lived access.
• Score the five CISA data functions twice a year with evidence for each stage claimed.

Standards and references

• CISA: Zero Trust Maturity Model Version 2.0
• NSA: Advancing Zero Trust Maturity Throughout the Data Pillar
• DoD CIO: Zero Trust Capabilities and Activities
• OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
• NIST: SP 800-207 Zero Trust Architecture
• NIST: SP 800-162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations

Related NHI Mgmt Group resources: CISA Zero Trust Maturity Model Guide · Zero Trust Identity Guide · Data Security Guide · Data Classification Guide