The Eighth Framework: NSAuditor AI Enterprise Maps NIST SP 800-171 Rev 2 at the Objective Level

NSAuditor AI Enterprise 0.40.0 adds NIST SP 800-171 Rev 2 as its eighth compliance framework, scoped as evidence substrate for CMMC Level 2 preparation. It routes from the same single, agentless, read-only scan that already produces SOC 2, HIPAA, NIST CSF 2.0, PCI DSS, ISO 27001, CIS Controls v8 and GDPR Article 32 evidence — and the interesting part is not that it exists, but the level it claims coverage at.

Requirements are what you read. Determination statements are what you are scored on.

NIST SP 800-171 Rev 2 defines 110 security requirements. NIST SP 800-171A — the assessment companion — decomposes each of those requirements into determination statements, and a C3PAO assessor scores every one of them individually. A requirement is not met because most of its objectives are satisfied; it is met when all of them are.

That distinction is where most tooling quietly loses the plot. A scanner that reports a percentage against 110 requirements is answering a question no assessor asks. This engine maps at the objective level instead: every mapped requirement carries the full list of its determination statements alongside the subset the scan supplies examine-method material for — 81 of 172 determination statements across the 51 mapped requirements.

A requirement is only reported as covered here when every one of its objectives is a statement about technical system state the scan reads directly. Most requirements retain at least one objective about a defined procedure, an identified set, or an authorization decision — and configuration cannot evidence any of those, in any product. Publishing the pair, rather than a single verdict, is what lets an assessor see exactly which objectives your infrastructure already evidences and which remain organizational work.

All 110 requirements are enumerated, with no declared subset

There is no partial universe here and therefore no under-enumeration surface. Every one of the 110 Rev 2 requirements is classified, and every out-of-scope group carries the written reason it is out of scope. Five families are operator-side in their entirety — awareness and training, incident-response execution, maintenance, personnel security, and physical protection — and the output says so rather than omitting them.

Where a requirement lands as partial, the output does not stop at the label. partialBasis names which of three distinct shortfalls the partial actually is, because “partial” otherwise hides three genuinely different situations and an assessor needs the shape of the gap, not its name.

Rev 2 is pinned deliberately

CMMC assesses Rev 2 by rule. Rev 3 is a different universe — 97 requirements carrying organization-defined parameters — and answering a Rev 3 question with Rev 2 output is drift dressed up as currency. The engine pins Rev 2 and says so.

What it is, stated as a scope rather than a disclaimer

• It supplies examine-method substrate for a subset of assessment objectives. Certification is a per-contractor C3PAO assessment outcome and stays there.
• It informs your System Security Plan and your POA&M. Those remain operator artifacts — they are what an assessment is conducted against, and this engine never produces them.
• CUI scope remains the operator’s assertion. The scanner reads infrastructure configuration; it cannot see CUI, cannot distinguish FCI from CUI, and cannot see an enclave boundary. Its offline operation fits enclave deployments; fitting inside a boundary is not defining one.

Two data fields were removed during development rather than shipped — a per-requirement scoring weight and a requirement-type classification. Both were transcriptions from sources this codebase does not hold, and an adversarial review disputed specific values in each. The rule applied is that a compliance datum ships only when the repository holds an authority it can be re-derived from.

One collision worth knowing about

NIST SP 800-171 requirement identifiers collide exactly with PCI DSS sub-requirement identifiers: 3.5.1 names a real requirement in both standards. Neither framework strips bare identifiers, because no rule could attribute one correctly. Both qualify their citations in prose instead. On any surface, write “NIST SP 800-171 3.5.1”, never a bare 3.5.1.

The eight matrices, in full

The PCI DSS figure is scoped to the 67 sub-requirements this engine can reach out of roughly 250 in the standard, not to the standard as a whole. The GDPR figure is Article 32 Security-of-Processing infrastructure substrate only, never GDPR compliance. The seven pre-existing matrices are unchanged in this cycle, and the plugin catalog is unchanged at 28 Enterprise plugins, 27 of them cloud auditors, 55 overall.

The rest of the cycle

--compliance nist-800-171 joins the other seven framework names, and all eight route from a single scan. The cycle also closed 53 per-dimension under-claims by derivation rather than by hand, classified foreign-account KMS custody at four producers (RDS, SQS/SNS, DynamoDB and GCS), and added a determination-vocabulary guard. Where a check genuinely cannot be made — an Azure Key Vault URI carries the vault name only, with no subscription or tenant — the code carries a capability-boundary comment at the point of use rather than guessing.

Versions and the peer floor

The current release is Enterprise Edition 0.40.1, paired with Community Edition 0.2.45 and agent-skill package 0.2.43. The Community Edition floor is raised to 0.2.45 at this cycle and it is a hard raise, not a courtesy pairing: framework-name validation lives in Community Edition, so --compliance nist-800-171 against an older Community Edition is rejected at the command line before Enterprise is consulted.

npm install -g nsauditor-ai@0.2.45 @nsasoft/nsauditor-ai-ee@0.40.1

Full coverage matrix and the auditor-facing walk-through: nsauditor.com/ai/docs/800-171/ · product overview: nsauditor.com/ai/enterprise/