Exhibit — collector coverage

Which mechanism reads which objective.

Each of the 320 assessment objectives in SP 800-171A was tested against one question: can a collector read the evidence the objective requires? Objectives are grouped by the mechanism classes that reach them and by whether the resulting evidence is fully reportable, partially reportable, or not reached at all. Select a family to see its objectives individually.

Standard NIST SP 800-171A Rev 2 Dataset v8.8 Objectives 320 Method single reference architecture, n=1

320 objectives, 418 attributions — an objective reached by more than one mechanism class appears once per class. Attributions derived from one reference architecture; in a different estate they must be re-derived, because the mechanism that reaches an objective depends on what is actually deployed.

143

Fully reportable

A collector reads the evidence the objective requires, in full. Tenant configuration API and host configuration read carry most of this, at 104 and 95 attributions.

80

Partially reportable

A collector reaches part of what the objective asks for. The remainder needs a person. Partial is not a rounding error toward full — it is its own state, and it is reported as one.

97

Not reached

Of these, 80 have no mechanism assigned at all. They are overwhelmingly definitional — policies defined, roles identified, processes established — which is the honest ceiling on automated evidence, not a backlog.

Methodology

The study was conducted against a fully compliant SP 800-171 Rev 2 enclave built to a single reference architecture: hardened Windows 11, Windows Server 2025 and Ubuntu 24.04 hosts, a Wazuh 4.14 manager, and an Entra/M365 tenant read through the Graph API. Every component is a commonly available building block of enterprise IT. Hardening on the hosts was enforced by script-applied local policy at build time, with Wazuh SCA acting as the drift detector afterward. Each of the 320 assessment objectives in SP 800-171A Rev 2 was evaluated individually, with the objective's determination-statement prose in view rather than its identifier, against a single question: can a collector in the reference architecture read the evidence this objective requires?

The evaluation proceeded in two passes.

Each attribution was judged as an assessor would evaluate it: would the evidence this mechanism produces satisfy an examiner reading the determination statement literally, with no inference from adjacent controls and no credit for what the mechanism could be configured to read but is not? Where the answer was yes for part of a statement and no for the rest, the objective was recorded as partial. The evaluation was made from both sides of that exchange - knowing what the mechanism actually emits and what an examiner would accept as evidence of it - which is why partials were not rounded up and why the 80 unreached definitional objectives are recorded as a ceiling rather than a backlog.

Attributions are recorded per mechanism class, not per host, so they carry to any enclave where the same class is deployed, and only to such an enclave. An enclave with no tenant configuration API cannot claim the 104 attributions that class provides here. Conversely, an enclave that deploys a mechanism this architecture does not - an EDR, a DLP engine, a PAM broker - may reach objectives this study records as not reached.