NSAuditor AI EE generates NIST Cybersecurity Framework 2.0 Core (NIST CSWP 29, February 2024) pre-audit gap reports mapped at the auditor-canonical Subcategory level. SHA-256 chain-of-custody sidecars, cover-page Scope Attestation, suppression workflow, honest OOS framing on Govern + Respond + Implementation Tiers — and Zero Data Exfiltration, so federal-contractor and DOD-adjacent customers can scan inside their own boundary.
CURRENT · EE 0.34.0 · 2026-08-10 Supply-chain gate integrity EE 0.33.1 · CE 0.2.38 · agent-skill 0.2.36
Current release — EE 0.33.1 (2026-08-07): auditor-verifiable proof, now stated in every framework report. All seven auditor-shaped reports now say the same thing about evidence integrity: RFC 3161 trusted timestamping is opt-in via NSAUDITOR_TSA_URL, pointed at a Time-Stamp Authority you choose, and every compliance artifact then carries a .tsr sidecar your auditor verifies offline with stock openssl — against that third party, with none of our software in the path. Opt-in with no default, ever, so an air-gapped environment simply leaves it unset. Verified end to end on 2026-08-07 against a real public Time-Stamp Authority through the published binaries. The agent skill and the Community Edition README answer the same way, so every surface a reader can reach agrees. It builds directly on EE 0.33.0 (2026-08-07), the wiring release. Eleven compliance options that nothing shipped could populate now receive values from a real entry point — the option existed, the engine read it, and nothing ever wrote to it. The new entry points live in Community Edition, so EE 0.33.0 requires CE ≥ 0.2.37; on an older CE the options stay unfed. Zero Data Exfiltration is restated as a positive register of 17 enumerated outbound paths, each with its trigger and its off switch, rather than a blanket denial — the form that survives a GV.SC / PR.DS review. RFC 3161 trusted timestamping is now opt-in via NSAUDITOR_TSA_URL, verified against a real timestamp authority on 2026-08-07 — opt-in, not a default, and itself one of those outbound paths. Ed25519 suppression signing is still NOT reachable from any shipped entry point. Signature records now carry algorithm and backend frozen at signing time rather than re-derived later. Matrix-neutral — all seven coverage matrices UNCHANGED, plugin count UNCHANGED at 28 Enterprise plugins (27 of them cloud auditors), 55 overall; this NIST CSF 2.0 matrix is UNCHANGED at 13 covered / 10 partial / 83 OOS. Paired CE 0.2.37 + agent-skill 0.2.35.
Prior — EE 0.32.11 (2026-08-05): a scan report has two jobs — find what is wrong, and be clear about what it did not look at. Ours was failing the second.
1. The summary was dropping a whole tier. The cloud-scan summary rendered CRITICAL, HIGH, MEDIUM, LOW and PASS. INFO was not a column — not zero, absent. On a real AWS account producing 62 INFO findings, 55 of them appeared in no summary anywhere, and several were the scanner’s own declarations of what it had not evaluated. INFO is now a column and rolls up by category.
2. “Not assessed” now has its own channel. Scope boundaries are labelled [SCOPE NOT ASSESSED] — deliberately not the evidence-gap badge, because “I could not verify this on this run” and “this release does not evaluate this at all” are different statements and an auditor needs to tell them apart. Surface nobody assessed must not read like surface assessed and found clean.
Also in that release: a new compliance_matrix tool returns the shipped coverage matrix for any of the seven frameworks, derived from the framework maps at call time rather than transcribed; a capability flag that was registered and printed but implemented nowhere is withdrawn, and every capability now ships a written description; and three GCP firewall verdicts that could read clean over unevaluated rules now fail closed. Matrix-neutral — 28 Enterprise plugins, 27 of them cloud auditors (55 overall), and seven frameworks, all unchanged. Paired CE 0.2.36 + agent-skill 0.2.34.
Prior — EE 0.32.11 (2026-08-05): the dependency-advisory release gate had been auditing the maintainer’s development tree while calling it the production closure. It now packs the tarball, installs it the way a customer does, and audits that — and refuses to report clean until an advisory database has actually answered.
Prior — EE 0.32.9 (2026-07-29): an internal-provenance strip plus a false-clean closure. A compliance report is a document you hand your assessor, and ours carried internal engineering identifiers — roadmap ids, internal release stamps, the name of an internal audit review — in finding titles, on the attestation cover page and in the chain-of-custody record. Measured on a rebuilt three-cloud evidence pack: 686 unexplained internal-marker occurrences → 0 across 105 files, with a positive control in the same run (3,572 benign matches still detected) so the zero is a measurement rather than an absence of looking. And when a cloud plugin could not start — optional SDK absent, credentials unusable — it refused to report, and that refusal evaporated one layer up: the compliance report came out byte-identical to one where the scanner ran and found nothing. Ten controls read PASS, no violation, no warning. For a Current Profile that is a silent overstatement of Subcategory posture. Every in-scope control of a cloud that could not be scanned now carries a fail-closed evidence gap. Also in that release: an archived scan re-processed by the new build WARNS instead of failing clean; four report surfaces that contradicted each other on trusted timestamping — which was still on the roadmap at that release, and became opt-in via NSAUDITOR_TSA_URL in EE 0.33.0 — now say the same verifiable thing; and a new pack scanner that fails closed when its own positive control comes back empty. The paired Community Edition 0.2.34 fixed --out <dir> writing to the parent directory when the directory name contains a dot. Two upgrade notes still apply: (1) the evidence-gap finding title changed at 0.32.9, so suppression rules written against the older text stop matching — the direction is safe (findings resurface rather than hide) but it is silent, so re-check your suppression list; (2) re-scan rather than re-processing scans captured before 0.32.9, as the engine now warns when it is handed an older archive.
Before that — EE 0.32.8 (2026-07-28): capability-claim honesty pass, part 2 — the air-gapped-delivery class. 27 advertised claims across the three published packages were checked against the code and withdrawn: an arm64 image (the build forces linux/amd64), offline-installable tarballs, monthly NVD feed bundles, an air-gapped install script, and a feed import CLI command with no implementation. Five of the 27 were not documentation but rendered runtime strings — the [COVERAGE GAP] rationale that prints verbatim into the assessor-facing evidence pack was telling the reader to import a feed with a command that does not exist. Nothing was withdrawn by deletion: the air-gap story was rewritten to what the code supports — a linux/amd64 delivery image or npm host install, fully offline ES256 license verification with no phone-home, and offline CVE matching under NSAUDITOR_OFFLINE_ONLY=1 — and ends with an explicit “deliberately not claimed” list, held by two mutation-proven guards. Matrix-neutral — no detection, routing or coverage change; still 28 EE plugins and all seven coverage matrices byte-identical to 0.32.7. The NIST CSF 2.0 matrix is UNCHANGED at 13 covered / 10 partial / 83 OOS. The paired Community Edition also fixes --out, which silently wrote to the parent directory when the output directory was version-named. Regression 9,280 pass / 0 fail. Paired CE 0.2.33 + agent-skill 0.2.31. And before that: EE 0.32.7 (2026-07-21) — cross-framework routing, so network-scan findings reach every framework that maps their control subject; matrix-neutral.
Subcategory-level mapping (institutional discipline): CSF 2.0 has 6 Functions × ~22 Categories × ~107 Subcategories. Auditors attach evidence at the Subcategory level — Categories are navigational headers. Category-level claims (e.g., "we cover PR.AA") don't pass institutional review.
Honest OOS framing — three architectural limits named upfront:
· Govern function OOS-by-design — 30 GV Subcategories explicitly OOS (policy/strategy/governance evidence). Single substrate-evidence exception: GV.SC-04 (suppliers known) partial via cross-account VPC endpoint inventory + backup-vault wildcard-Principal trust.
· Respond function OOS-entirely — 13 RS Subcategories explicitly OOS (incident-response runbook execution; engine produces the substrate adverse-events via DE.AE-02 but cannot evidence runbook execution).
· Implementation Tiers 1-4 OOS (Partial / Risk-Informed / Repeatable / Adaptive) — organizational-maturity claims; engine surfaces a cover-page OOS disclaimer naming Tugboat Logic / Drata NIST CSF / Vanta NIST CSF / AuditBoard as the appropriate pairings.
3-framework evidence pack from one scan: --compliance soc2,hipaa,nist-csf produces three complete auditor-ready evidence packs. SOC 2 reports cite CC IDs; HIPAA reports cite §164.312 specs; NIST reports cite Subcategory IDs (DE.CM-01, PR.AA-01, RC.RP-03). No new framework; this NIST CSF 2.0 matrix (13 / 10 / 83) is UNCHANGED — 28 plugins and all seven coverage matrices unchanged.
npm install -g nsauditor-ai@0.2.38 @nsasoft/nsauditor-ai-ee@0.33.1
NIST CSF 2.0 released February 2024 (NIST CSWP 29). Structure: 6 Functions (Govern NEW in 2.0, Identify, Protect, Detect, Respond, Recover) × ~22 Categories × ~107 Subcategories. Most-requested next framework after SOC 2 + HIPAA for federal contractors, DOD-adjacent organizations, critical-infrastructure operators, and DFARS/CMMC pre-audit preparation. NSAuditor's engine is framework-agnostic — see the SOC 2 coverage matrix and HIPAA §164.312 coverage matrix for the companion frameworks.
NSAuditor AI EE generates NIST CSF 2.0 Core Subcategory-level evidence — at the same institutional grade as SOC 2 and HIPAA. It maps cloud infrastructure findings (AWS, Azure, GCP) and network scan results to specific Subcategory IDs (PR.AA-01, DE.CM-01, RC.RP-03, etc.), produces hash-chained evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, and a documented suppression workflow), and ships NIST reports in machine-readable form suitable for NIST-aware GRC platform ingestion.
It is not a complete NIST CSF 2.0 attestation (the Govern function is OOS-by-design except GV.SC-04 partial; the Respond function is OOS-entirely). It is not an Implementation Tier 1-4 attestation (Tiers are organizational-maturity claims; pair with Tugboat Logic / Drata NIST CSF / Vanta NIST CSF / AuditBoard). It is not a NIST SP 800-53 control attestation (NIST CSF 2.0 cites SP 800-53 as Informative References, but SP 800-53 is a separate framework planned for a future cycle). It is not a NIST AI RMF attestation (also future).
What it IS: the Subcategory-level technical-evidence layer covering Protect (PR.AA + PR.DS + PR.PS + PR.IR), Detect (DE.CM + DE.AE), Recover (RC.RP), parts of Identify (ID.AM + ID.RA), and the GV.SC-04 substrate exception — complete and auditor-ready. Compatible with operator-side NIST CSF 2.0 Profile development, DFARS/CMMC pre-audit gap analysis, and federal-contractor security-questionnaire response. Honest about what infrastructure scanning fundamentally cannot evidence (Tiers + Govern + Respond) — saves you from the textbook NIST-auditor overclaim findings.
The market split: NIST-aware GRC platforms (Tugboat Logic, Drata NIST CSF, Vanta NIST CSF, AuditBoard) automate Profile development + organizational-maturity self-assessment + policy-template workflows but lack deep cloud-infrastructure scanning at the Subcategory-evidence level. Legacy scanners (Tenable, Qualys, Rapid7) produce voluminous CVE reports but don't map findings to CSF 2.0 Subcategory IDs. NSAuditor's wedge is the bridge — deep cloud + network scanning + NIST CSF 2.0 Subcategory-mapped output + same Zero Data Exfiltration architecture used for SOC 2 + HIPAA (no cloud round-trip of scan data; air-gapped operation supported).
NIST CSF 2.0 Core has a 3-level hierarchy:
NIST CSF 2.0 informative-references documentation (the NIST OLIR catalog) maps Subcategories to SP 800-53 Rev. 5 controls + CIS Critical Security Controls v8 Safeguards + ISO 27001:2022 controls — all at the Subcategory level. Auditor-canonical evidence is per-Subcategory. Category-level claims (e.g., "we cover PR.AA") don't survive institutional review; auditors will ask which Subcategories of PR.AA, with what evidence.
NSAuditor maps at the Subcategory level. Per-Subcategory fields in data/compliance/nist-csf.json:
| Field | Type | Purpose |
|---|---|---|
id | string | Subcategory ID in canonical CSF 2.0 form: FUNCTION.CATEGORY-SUBCATEGORY (e.g., PR.AA-01). |
function | enum | One of GV / ID / PR / DE / RS / RC. |
categoryCode | string | Two-letter Category code (e.g., AA, CM, RP). |
subcategory | string | Two-digit Subcategory ordinal (e.g., 01, 02). |
outcomeText | string | NIST's verbatim outcome statement for the Subcategory (the auditor-citation-source-of-truth). |
informativeReferences | string[] | NIST SP 800-53 Rev. 5 control IDs + CIS Critical Security Controls v8 Safeguard IDs cited as NIST-published informative references (2024 snapshot). |
A schema-additive-fields propagation test enforces these fields reach the rendered report (closes the "ghost-schema" class — fields declared in JSON but never surfaced to auditors).
Source of truth is data/compliance/nist-csf.json; this matrix mirrors it. The anchor-drift defense test asserts every (source, titlePattern) pair in nist-csf.json exists in soc2.json (inheritance contract — closes the silent false-CLEAN class at the NIST mapping layer, parallel to HIPAA's inheritance defense).
| Function | Covered | Partial | OOS | Notes |
|---|---|---|---|---|
| GV | 0 | 1 GV.SC-04 |
30 | Govern function OOS-by-design (policy/strategy/governance). Single substrate-evidence exception: GV.SC-04 (suppliers known) partial via cross-account VPC endpoint inventory + backup-vault wildcard-Principal trust. |
| ID | 2 | 2 | 17 | Identify — covered: ID.AM-01 hardware inventory + ID.AM-03 authorized network flows. Partial: ID.AM-02 software inventory (substrate, needs SBOM) + ID.RA-01 vulnerabilities identified (substrate, needs operator triage). |
| PR | 8 | 4 | 10 | Protect — the strongest function in the matrix. Covered: PR.AA-01, PR.AA-03, PR.AA-05, PR.DS-01, PR.DS-02, PR.DS-11, PR.PS-04, PR.IR-01. Partial: PR.DS-10, PR.PS-01, PR.PS-02, PR.IR-03. |
| DE | 2 | 2 | 7 | Detect — covered: DE.CM-01 (networks monitored) + DE.CM-09 (computing hardware/software monitored). Partial: DE.CM-03 (personnel activity monitored — substrate via CloudTrail) + DE.AE-02 (adverse events analyzed — substrate via intelligence engine). |
| RS | 0 | 0 | 13 | OOS-entirely. Incident-response runbook execution evidence — operator-side. Pair with TheHive / IBM Resilient / Demisto/Cortex XSOAR / Splunk SOAR + IR runbook + tabletop-exercise log archive. |
| RC | 1 | 1 | 6 | Recover — covered: RC.RP-03 (backup integrity verified before restoration). Partial: RC.RP-04 (mission-function prioritization — substrate via Object Lock). |
| Total | 13 | 10 | 83 | 106 of 107 Subcategories enumerated (the engine accounts for substantially all of CSF 2.0 Core). |
Once EE is installed and licensed, NIST CSF 2.0 evidence generation is a one-flag operation:
The engine emits standard render targets (Markdown for auditor distribution, HTML for browser/GRC consumption, JSON for machine ingestion, CSV for spreadsheet review). NIST CSF reports include the Implementation Tiers OOS disclaimer section between the cover-page status and per-Subcategory sections — surfaces upfront that infrastructure scanning does NOT evidence Tiers per-control.
The engine is framework-agnostic. A single scan with three framework targets produces three complete evidence packs, each citing its own framework's control IDs:
Each report's per-framework citation map cites only its own framework's control IDs. SOC 2 reports never cite §164.312 or PR.AA-01. HIPAA reports never cite CC IDs or PR.AA-01. NIST reports never cite CC IDs or §164.312. Cross-framework citation-leak defense is enforced in all 3 directions by 91 net tests across 3 test files.
The same scan, same set of cloud-API calls, same findings — three frameworks. This is the institutional value prop for organizations preparing simultaneous SOC 2 + HIPAA + NIST CSF audits (or selectively responding to RFP security questionnaires that cite different frameworks).
NIST CSF 2.0 reports follow the same auditor-grade artifact pattern as SOC 2 and HIPAA:
scan_compliance_nist-csf.md) — primary auditor distribution format. Cover-page Scope Attestation, Implementation Tiers OOS disclaimer, per-Subcategory sections with covered / partial / OOS framing, audit-canonical Subcategory IDs as headings.scan_compliance_nist-csf.html) — browser / GRC-platform render. Same content as markdown including the Implementation Tiers OOS disclaimer section (markdown + HTML render-path parity).scan_compliance_nist-csf.json) — machine-readable structured envelope for GRC connector push (Vanta + Drata + Secureframe shipped, opt-in early-access). Per-Subcategory schema-additive fields propagated: function, categoryCode, subcategory, outcomeText, informativeReferences.scan_compliance_nist-csf.csv) — spreadsheet-friendly tabular view for stakeholder review.scan_compliance_nist-csf.{md,html,json,csv}.sha256) — chain-of-custody integrity manifests. Auditors can verify offline with shasum -a 256 -c <file>.sha256.scan_compliance_nist-csf.*.tsr) — opt-in as of EE 0.33.0: set NSAUDITOR_TSA_URL to a Time-Stamp Authority of your choosing and each artifact gets a trusted-timestamp sidecar an auditor verifies offline with openssl ts -verify, against the authority’s own chain. Opt-in with no default — leave it unset and no outbound call is made.13 Subcategories are covered with direct substrate evidence from the 27 cloud plugins + network scanners. Below is the canonical citation set:
| Subcategory | Function | Outcome | Substrate evidence sources |
|---|---|---|---|
| ID.AM-01 | Identify | Hardware inventory maintained | aws-vpc-endpoints-auditor — VPC endpoint enumeration in-account. |
| ID.AM-03 | Identify | Authorized network communication flows | aws-ec2-sg-perimeter-auditor + azure-nsg-auditor — SG / NSG inbound-rule emissions. |
| PR.AA-01 | Protect | Identities and credentials managed | aws-iam-deep-auditor (MFA) + auth_agent (SSH password / Telnet). |
| PR.AA-03 | Protect | Users, services, hardware authenticated | aws-iam-deep-auditor + auth_agent (SNMP default community / Anonymous FTP). |
| PR.AA-05 | Protect | Access permissions least-privilege | aws-iam-deep-auditor (SHADOW ADMIN, Shadow admin path, PassRole privesc) + azure-rbac-auditor (Owner / Contributor) + gcp-iam-project-auditor (allUsers). |
| PR.DS-01 | Protect | Confidentiality of data-at-rest | aws-rds-auditor (StorageEncrypted) + aws-s3-auditor (No default encryption) + aws-iam-effective-decrypt-auditor + azure-keyvault-auditor + aws-kms-auditor. |
| PR.DS-02 | Protect | Confidentiality of data-in-transit | crypto_agent (SSLv2/v3, TLSv1.0/v1.1, weak cipher suites) + aws-rds-auditor (SSL enforcement) + aws-elasticache-redis-auditor (transit encryption) + aws-sqs-sns-auditor (SecureTransport Deny). |
| PR.DS-11 | Protect | Backups created, protected, maintained, tested | aws-dynamodb-auditor (PITR + deletion protection) + aws-backup-auditor (LogicallyAirGappedBackupVault PASS substrate) + aws-s3-auditor (Versioning). |
| PR.PS-04 | Protect | Log records generated | aws-cloudtrail-auditor (no trails / not multi-region / log file validation disabled) + aws-rds-auditor (pgAudit DISABLED). |
| PR.IR-01 | Protect | Networks protected from unauthorized access | aws-ec2-sg-perimeter-auditor + azure-nsg-auditor + aws-iam-deep-auditor (WITHOUT MFA). |
| DE.CM-01 | Detect | Networks monitored for adverse events | aws-cloudtrail-auditor (trail health) + aws-inspector-guardduty-auditor (GuardDuty NOT ENABLED + missing detector features). |
| DE.CM-09 | Detect | Computing hardware/software monitored | aws-cloudtrail-auditor (log file validation) + aws-rds-auditor (pgAudit) + aws-inspector-guardduty-auditor (Inspector2 DISABLED). |
| RC.RP-03 | Recover | Backup integrity verified before restoration | aws-backup-auditor (LogicallyAirGappedBackupVault + Vault Lock) + aws-s3-auditor (Object Lock not configured). |
10 Subcategories are partial — the engine evidences a substrate dimension but cannot evidence the full outcome (typically because part of the outcome requires operator-side process / SBOM / RTO-RPO planning / supplier registry data the engine doesn't have). Every partial control carries a partialReason field surfacing what the engine evidences vs what the operator must supply:
| Subcategory | What engine evidences (substrate) | Operator-side completion |
|---|---|---|
| ID.AM-02 | Managed-service enumeration (RDS, DynamoDB, Lambda, S3, Key Vault, GCS) + configuration drift findings | SBOM (CycloneDX, SPDX) keyed by managed service; per-service application owner + criticality classification. |
| ID.RA-01 | CVE-class vulnerability identification + misconfiguration class via cloud plugins + COVERAGE GAP transparency | Manual triage of "validated" dimension (does this CVE apply to deployed config?); ticketing-system integration with vuln lifecycle. |
| PR.DS-10 | Confidentiality+integrity substrate (KMS-CMK key custody, IAM boundary, Object Lock immutability) | Memory-encryption / confidential-computing / TEE-attestation posture (Nitro Enclaves, Azure Confidential VMs, GCP Confidential VMs). |
| PR.PS-01 | Per-finding configuration drift on managed services; CloudTrail / Config recorder presence | Configuration baselines (AWS Config conformance packs, Azure Policy initiatives, GCP Organization Policy constraints); drift-detection cadence; configuration-as-code adoption. |
| PR.PS-02 | Outdated/vulnerable-software identification via CVE matching + EoL detection | Patch-cycle cadence: time-from-CVE-publication to patch-deployment for CRITICAL (≤14 days), HIGH (≤30 days), MEDIUM (≤90 days), LOW (best-effort). |
| PR.IR-03 | Backup-substrate (PITR, deletion-protection, Object Lock, Air-Gapped Vault, single-AZ vs Multi-AZ RDS) | RTO/RPO definition per workload; DR tabletop exercise cadence (typically annual minimum); failover-testing posture for tier-1 workloads. |
| DE.CM-03 | CloudTrail / Azure Activity Log / GCP Cloud Audit Logs substrate for personnel-activity monitoring | SIEM/UEBA platform receiving the substrate; behavioral-analytics rules for insider-threat patterns (off-hours admin, mass data download, unusual cross-account assume-role). |
| DE.AE-02 | Adverse-event substrate (security findings) + intelligence engine CVE context | SOC analyst playbooks per top adverse-event class; deep correlation across log streams; SOAR playbook integration. |
| RC.RP-04 | Object Lock substrate evidences post-incident-immutability anchor | Critical-mission-function inventory with RTO/RPO targets; cybersecurity-risk-management acceptance signoffs by appropriate stakeholders. |
| GV.SC-04 | VPC endpoint inventory + cross-account VPC endpoint policies + backup-vault wildcard-Principal trust as supply-chain-trust surface | Supplier inventory (TPRM platform — OneTrust, Vanta vendors, Drata vendors); criticality ranking per supplier (tier 1/2/3 or equivalent); tier-1 supplier security questionnaire responses + SOC 2 reports. |
The Govern function (NEW in NIST CSF 2.0 vs 1.1) is the policy / strategy / governance dimension of the framework: GV.OC Organizational Context, GV.RM Risk Management Strategy, GV.RR Roles, Responsibilities, Authorities, GV.PO Policy, GV.OV Oversight, and GV.SC Supply Chain Risk Management. These are governance, executive-oversight, board-level, and policy-cycle evidence streams.
30 of 31 GV Subcategories are OOS by architectural design. They require board minutes, risk-register documents, signed policies, formal supplier-risk frameworks, and organizational-charter documentation — none of which infrastructure scanning can produce. Pair NSAuditor with a NIST-aware GRC platform (Tugboat Logic, Drata NIST CSF module, Vanta NIST CSF, AuditBoard) for Govern coverage.
The single substrate-evidence exception is GV.SC-04 (Suppliers are known and prioritized by criticality) — partial via cross-account VPC endpoint inventory + backup-vault wildcard-Principal trust. The engine evidences "suppliers known" through the technical supplier-trust surface (each VPC endpoint = a cross-account or cross-service trust); the "prioritized by criticality" dimension is operator-side (TPRM data the engine doesn't have). The partial rationale surfaces this distinction explicitly in the rendered report.
This OOS-by-design framing is parallel to HIPAA §164.308 + §164.310 (administrative + physical safeguards) and SOC 2 CC1.x + CC2.x + CC3.x + CC4.x + CC5.x (governance, communication, risk assessment, monitoring activities, control activities).
The Respond function (RS.MA Incident Management, RS.AN Incident Analysis, RS.CO Reporting and Communication, RS.MI Incident Mitigation) is entirely incident-response runbook execution evidence — post-incident reports, IR-tool logs, tabletop-exercise results, communication records to regulators / customers / law enforcement, containment / eradication action records.
All 13 RS Subcategories are OOS. Infrastructure scanning produces the inputs (the original adverse-event substrate via DE.AE-02 + the substrate findings the IR team consumes) but cannot evidence the IR-runbook execution itself. Pair NSAuditor with operator's IR platform (TheHive, IBM Resilient, Demisto/Cortex XSOAR, Splunk SOAR) + IR runbook + tabletop-exercise log archive.
This OOS-entirely framing is parallel to HIPAA §164.308(a)(6) Security Incident Procedures and SOC 2 CC7.4 (Respond to Identified Incidents) — the engine evidences the substrate that incident-response programs consume but not the response itself.
NIST CSF 2.0 Implementation Tiers (Tier 1 Partial → Tier 2 Risk-Informed → Tier 3 Repeatable → Tier 4 Adaptive) describe the maturity of cybersecurity-risk-management practices across the enterprise. They are organizational-maturity claims at the program level — NOT per-control configuration state.
Tiers are the textbook NIST-auditor overclaim risk. If a vendor surfaces a per-control Tier claim or "we're at Tier 3" assertion based on infrastructure scanning alone, the auditor flags it immediately. Tiers require evidence streams (governance / risk-management / supplier-relationship / training program data) that no infrastructure scanner can produce. NSAuditor refuses to make per-control Tier claims by architectural design — the engine NEVER emits a Tier field per Subcategory.
Instead, NIST CSF reports include an Implementation Tiers OOS disclaimer section near the cover page (markdown + HTML render-path parity, gated on isNistCsfReport) that explicitly states what infrastructure scanning CAN and CANNOT evidence. The disclaimer cites the appropriate pairings:
The honest framing is the institutional value prop. A vendor that overclaims Tiers fails NIST auditor scrutiny; a vendor that names the OOS surface upfront passes.
NIST CSF 2.0 does not formally use Type-I / Type-II terminology (that's SOC 2 / SSAE 18 convention). NIST CSF audits typically expect:
scan_compliance_nist-csf.* artifacts.
The same architectural principle that makes NSAuditor AI EE a Zero-BAA tool for HIPAA applies to NIST CSF 2.0 federal deployments: no scan data, cloud-API credential or evidence artifact is ever transmitted to Nsasoft — we do not see, store or process any of it. Every outbound path the product can take is enumerated in its published egress register, so the claim is one you can audit rather than one you have to trust. The scanner is self-hosted; AI analysis runs locally (Ollama) or via the customer's own API keys (OpenAI, Anthropic); reports are written to the customer's local out/ directory.
This is the institutional differentiator for federal contractors + DOD-adjacent customers preparing DFARS/CMMC pre-audit. ITAR-restricted, CUI-handling, or classified-adjacent infrastructure cannot use SaaS GRC platforms for scan ingestion — scan data flowing to a SaaS vendor is itself a potential DFARS/ITAR violation. NSAuditor's air-gapped operation is compatible with the FedRAMP / DFARS / CMMC threat model where SaaS data flow is prohibited.
NIST-aware GRC platforms (Tugboat Logic, Drata NIST CSF, Vanta NIST CSF, AuditBoard) are SaaS and pair with NSAuditor for the OOS surfaces they specialize in — Govern + Respond + Tiers — without ingesting the raw scan data or cloud credentials. The Profile-level (organizational-maturity) data they consume is sanitized policy + workflow data, not infrastructure substrate.
| Category | Vendor | Wedge | NSAuditor differentiation |
|---|---|---|---|
| NIST-aware GRC | Tugboat Logic, Drata NIST CSF, Vanta NIST CSF, AuditBoard | Profile development, Tier self-assessment, policy templates, supplier-risk workflow | NSAuditor produces the Subcategory-level technical substrate evidence GRC platforms cannot. Complement, not replacement. |
| Legacy security scanners | Tenable, Qualys, Rapid7 | CVE detection at scale | NSAuditor produces NIST CSF Subcategory-mapped evidence (the format auditors actually want) rather than raw CVE lists with no framework mapping. |
| NIST consulting firms | Coalfire, A-LIGN, Kratos | DFARS/CMMC audit + advisory services | NSAuditor produces the pre-audit Subcategory gap report the consultant builds the audit on top of — reduces consultant billable hours. |
| AWS-native NIST | AWS Audit Manager (NIST CSF framework) | Pre-built control assessments using AWS Config | AWS Audit Manager covers AWS-only and maps at the Category level (not auditor-canonical Subcategory level). NSAuditor adds Azure + GCP + on-prem + cross-cloud bucket dedup + GRC platform push + WORM evidence storage. AWS Audit Manager doesn't produce institutional-grade evidence artifacts (no chain-of-custody envelope, no cover-page scope attestation). |
Subcategory level — the auditor-canonical granularity. Functions and Categories are navigational headers; Subcategories are the outcome statements auditors attach evidence to.
30 of 31 GV Subcategories require policy/strategy/governance evidence streams (board minutes, risk-register documents, signed policies, supplier-risk frameworks) that infrastructure scanning cannot produce. The single substrate-evidence exception is GV.SC-04 (suppliers known) via cross-account VPC endpoint inventory + backup-vault wildcard-Principal trust.
All 13 RS Subcategories are incident-response runbook execution evidence — post-incident reports, IR-tool logs, tabletop-exercise results. Pair with operator's IR platform (TheHive, IBM Resilient, Demisto/Cortex XSOAR, Splunk SOAR) + IR runbook + tabletop-exercise log archive.
Tiers 1-4 (Partial / Risk-Informed / Repeatable / Adaptive) are organizational-maturity claims explicitly OOS. The engine NEVER emits a per-control Tier claim. Reports include a cover-page Implementation Tiers OOS disclaimer (markdown + HTML parity) naming Tugboat Logic / Drata / Vanta / AuditBoard as the appropriate pairings.
Both planned. SP 800-53 Rev. 5 is already cited as Informative References on covered/partial Subcategories. AI RMF is relevant when EE plugins start covering ML/AI workloads. Neither ships today.
Every (source, titlePattern) pair in nist-csf.json MUST exist in soc2.json (defended by tests/nist_csf_mapping_anchor_drift.test.mjs). Closes the silent false-CLEAN class at the NIST mapping layer. Parallel to HIPAA's inheritance defense.
Partially. NSAuditor produces the technical-substrate dimension of the Current Profile (per-Subcategory configuration state). Target Profile + Action Plan + Implementation Tier self-assessment + organizational-context + supplier-risk-prioritization data are operator-side — pair with GRC Profile workflow.
DFARS 252.204-7012 + CMMC Level 2/3 cite NIST SP 800-171 + SP 800-172 — which themselves derive from NIST CSF / SP 800-53 control families. NSAuditor's Subcategory-level NIST CSF 2.0 evidence directly informs the Current Profile dimension a DFARS/CMMC pre-audit consultant builds on top of. Air-gapped operation is compatible with ITAR / CUI handling threat model.
No — explicitly only NIST CSF 2.0 (Core; NIST CSWP 29, February 2024). CSF 1.1 is superseded. The version pin is enforced in data/compliance/nist-csf.json version: "2.0" and reflected in the rendered frameworkLabel.