FY2027 is here: what the DoD Zero Trust data pillar requires, and what storage has to prove

Fiscal year 2027 began on October 1, and it is the deadline year. The DoD Zero Trust Strategy, issued in 2022, requires Department of War (DoW, formerly DoD) components to achieve the Target Level outcomes of every Zero Trust capability no later than the end of FY2027, which falls on September 30, 2027. The strategy defines Target Level as the minimum set of outcomes and activities needed to protect the department’s data, applications, assets, and services against currently known threats.

In many programs, early progress came in identity and networking, where products were mature and results were easy to show. The data pillar is where a great deal of the remaining work sits, and it is the pillar in which storage decisions matter most. This guide walks through what the pillar requires at Target Level, capability by capability, and separates the activities the storage layer can carry from the ones it can only support.

DoD’s capability execution roadmap breaks the Zero Trust model into 45 capabilities and 152 activities, 91 of them at Target Level. The data pillar accounts for seven of those capabilities and 31 of the activities. Seventeen are Target Level, which puts them inside the FY2027 deadline, and the other 14 are Advanced. The table lists each capability’s Target activities next to what RackTop BrickStor SP contributes at the storage layer, including where an enterprise program has to do the rest.

Activity 4.2.3 asks the enterprise and components to determine whether software-defined storage is in use, develop policy and standards for it, and evaluate current storage strategy and technology for SDS. The enterprise also defines minimum attribution requirements for SDS to support Zero Trust. That assessment is the natural moment to ask whether the NAS platforms holding CUI and other regulated files can carry attributes and enforce policy at all. BrickStor SP is software-defined NAS that enforces attribute-based policy, including data labels, on every SMB, NFS, S3, and Web Drive operation.

Activities 4.4.3 and 4.4.4 require file activity monitoring, first for the most critical data classifications and then for all regulatory protected data such as CUI, PII, and PHI, with analytics fed into the SIEM and extended to tools such as DLP and user and entity behavior analytics. Active Defense does this inside the storage system. It inspects each file operation with the identity, source address, path, operation type, and timing attached, compares it against behavioral baselines for each user, host, and dataset, and records every operation in an immutable audit that includes the user’s attributes, the resource, the action, the decision, and the policy rule that applied. Because the monitoring happens where the files are served, coverage does not depend on agents on every endpoint or on a log feed the storage chooses to export.

Activity 4.7.4 integrates access-control and data-location attributes, and the DLP, DRM, and storage tools that use them, with the enterprise identity provider through interfaces such as APIs, LDAP, and SAML. BrickStor SP consumes attributes from Active Directory, LDAP, and other sources and applies attribute-based decisions from engines such as Sentris to each operation. That per-operation enforcement on software-defined storage is also what the Advanced activities 4.7.3 and 4.7.5 describe, so the platform that meets the Target integration supports the Advanced outcomes that follow.

Several Target activities belong to the enterprise. A data catalog aligned to risk (4.1.1), tagging and interoperability standards (4.2.1 and 4.2.2), and the classification tools that decide what a document is (4.3.1) are programs and tools that storage feeds rather than replaces. The same goes for document-level rights management that travels with a file after it leaves the repository, and for content-inspection DLP on endpoints and email.

What the storage layer adds is enforcement where the data actually lives. Labels on the data make tagging standards enforceable, per-operation audit gives the catalog and the SIEM ground truth about access, and behavioral detection on reads catches the bulk collection that DLP rules can miss. An assessor will still look for the enterprise programs, and storage-layer controls are what make those programs hold on the file shares where most unstructured data sits.

With less than a year left, sequencing matters as much as coverage. The fastest gains usually come from finding where regulated files actually live, which is often on file shares and NAS platforms that predate the program, and deciding in the 4.2.3 assessment which of those platforms can carry attributes and enforce policy. File activity monitoring for the most critical data, feeding the SIEM, addresses 4.4.3 and builds the baseline that 4.4.4 extends to all regulated data. Validated encryption with managed keys addresses the at-rest protection in 4.5.3, and integrating storage with the enterprise identity provider addresses 4.7.4.

Building these controls into the storage platform also helps with accreditation, because logging, attribute-based access control, validated encryption, and immutable audit are present by design instead of assembled from separate tools. RackTop’s federal engineers can walk a component or integrator through how BrickStor SP maps to its own Target Level plan, and put the platform in its environment to test it.