NIST's AI cybersecurity guide makes "Not addressed" a valid result
Give a model policies, interview notes, risk registers, and audit findings, and it can produce a tidy cybersecurity table. The dangerous row is the one where no evidence exists but the model supplies a plausible sentence anyway.
NIST's new draft guide for using AI with the Cybersecurity Framework 2.0 is built around that risk. Its sample prompts tell the model to stay within supplied evidence, cite support for each conclusion, expose assumptions, and say when an outcome is not addressed. CO-STAR provides the prompt structure. Preserving blank spaces provides the control.
The draft covers three jobs
NIST published the initial draft of Special Publication 1353 on August 19, 2026. Comments are due October 15. The nine-page quick-start guide describes three notional uses for generative AI:
- Review policies and strategy against the CSF 2.0 Govern function.
- Draft a Current State Profile from organizational artifacts and interviews.
- Draft a Target State Profile from internal requirements, risk information, and industry references.
These are drafting and analysis exercises. NIST says the examples are not prescriptive assessment or assurance methodologies. It also says the tools, services, profiles, and software used during prompt research are not recommendations or endorsements.
The CSF 2.0 is a taxonomy of cybersecurity outcomes. It does not prescribe one implementation for reaching them. A model may help map evidence to those outcomes. The resulting spreadsheet is still not an audit opinion.
A good prompt permits failure
The Current State Profile prompt restricts the model to attached source materials. If an outcome is absent, the model should say so plainly. It must map each outcome to the requirement or risk response that drives it, cite the source, and add an "Assumptions & Evidence Gaps" note.
The Governance Review prompt adds three limits: no inference beyond the supplied artifacts, no maturity scoring, and no benchmarking unless a benchmark was explicitly provided. Its statuses are Aligned, Partial, Misaligned, and Not addressed, each supported by evidence.
AI-assisted reporting often treats every empty cell as a request for prose. A weakly supported cell becomes an invitation to complete the pattern. In cybersecurity, that can hide the gap the assessment was supposed to find.
"Not addressed" is a successful output. So are "source silent," "assumption requires review," and "documented process without observed practice." These labels may make a report look unfinished. They also show the reviewer where the evidence ends.
Provenance belongs in every row
The draft recommends retaining identifiers, source context, provenance, and status for AI-assisted mappings and crosswalks. Practitioners should also confirm that reference material reflects the current published version before automated analysis.
Models used for security or compliance work can follow a similar output contract:
outcome_id: GV.RR-02
status: proposed
finding: "..."
evidence_refs:
- policy-04#section-7
assumptions: []
evidence_gaps:
- "No interview evidence for operating practice"
reviewer: null
source_version: "CSF 2.0"
This schema is an editorial recommendation, not a NIST template. It keeps a generated conclusion attached to reviewable evidence. proposed remains visibly different from an accepted finding, and a missing reviewer blocks the row from becoming authoritative.
A retrieval system can help if it returns stable document IDs and source locations with the text. Detached excerpts leave the reviewer with no path back to the original record.
Privacy review comes before upload
The guide tells organizations to choose tools authorized by their security and privacy teams. Before entering sensitive material, practitioners should review data retention, model-training use, access privileges, confidentiality terms, and company policy. Source artifacts must also be cleared for ingestion into that tool.
Current-state assessments may contain vulnerabilities, penetration-test results, staff interview notes, internal requirements, and risk registers. Sending those records to the wrong service creates a new security problem before the assessment begins.
Our Zero Data Retention audit guide applies the same rule to model APIs: retention policy covers only part of the data path. Logging, gateways, files, tool calls, and downstream processors need separate review. If a team compares models through an endpoint such as api.ish.chat, the test corpus should remain synthetic or approved until the full path is documented.
Review is a separate task
SP 1353 says qualified personnel should review AI-generated content before it informs organizational decisions. Users remain responsible for validating applicability, scope, inputs, assumptions, and outputs. NIST also suggests comparing results from multiple AI tools.
Agreement between models is not proof. Two systems can produce the same unsupported mapping because they learned similar language and received the same ambiguous evidence. Reviewers must return to the source files, check each cited location, and challenge rows with missing or conflicting evidence.
Separate generation from acceptance:
- Freeze the framework version and the approved source set.
- Generate proposed mappings with evidence references and explicit gaps.
- Reject any row that lacks a source or presents an assumption as fact.
- Have a named subject-matter reviewer accept, revise, or reject each material finding.
- Store the prompt, model version, source manifest, output, and review decision together.
- Re-run only when a source, framework, or model changes, and compare the diff.
The draft notes that generated results are point-in-time outputs and may vary. A polished report without its source manifest and review history is hard to defend later. Keep every generated row in proposed status until a named reviewer checks its evidence.
