NIST AI 600-1 Profile in 20 Minutes - What Auditors Care About
NIST AI 600-1 looks intimidating because it is forty pages and four function families. In practice, auditors come back to the same three controls in nine cases out of ten: MAP-2.3 (misuse identification), MEASURE-2.3 (test for misuse resistance), and MANAGE-2.2 (treatment of risks). Get those wired and the rest of the audit is structure.
We have walked customers through NIST AI 600-1 fifteen or sixteen times in the last quarter and the conversation always goes the same way. The compliance lead arrives with the PDF, the engineering lead has not read it, and twenty minutes later both of them realise the document is shorter than they thought and the gap between what they have and what NIST asks for is also shorter than they thought. This post is what we usually say.
What NIST AI 600-1 actually is
It is the Generative AI Profile under the NIST AI Risk Management Framework, published as a 2024 companion to the broader AI RMF Playbook. The Profile takes the four functions in the RMF (GOVERN, MAP, MEASURE, MANAGE) and lists which sub-categories apply to generative AI systems specifically. Some are reused unchanged, some are tightened, a few are new.
It is not a regulation. It is voluntary guidance. But two things make it carry weight in practice: the National Institute of Standards and Technology is the canonical reference for US federal procurement, and the EU AI Act references it indirectly through the harmonised standards process. If you are selling AI into a federal customer or onto a regulated balance sheet, NIST AI 600-1 is the document the procurement question wraps around.
The four functions in plain language
A condensed version. Read the NIST PDF for the precise language.
GOVERN. Policies, roles, training, and accountability. Most enterprises already have a version of this for general security; the new bit is naming an AI risk owner and an escalation path that does not bottleneck on the CISO.
MAP. Identify the AI system's context, intended use, capabilities, and limitations. This is where the asset inventory shows up; if you cannot list the system, you cannot map its risks. The hard sub-category here is MAP-2.3 on adversarial misuse identification, because most organisations have not done it.
MEASURE. Test the system against the risks identified in MAP. This is where adversarial scans, fairness tests, and robustness tests live. Auditors look for evidence that testing actually happened, not that a testing plan exists.
MANAGE. Prioritise, treat, and monitor identified risks. The audit looks for the bridge between findings and decisions: did someone read the finding, did someone make a call, and is there a record.
The three controls auditors ask about every time
We have watched fifteen audit walk-throughs. The same three sub-categories come up in almost every one.
MAP-2.3 - Adversarial misuse identification
The auditor wants to see a documented threat model: who would attack this system, with what motivation, through which attack surface. Most teams have this implicitly in their heads; very few have it on paper. The version that survives audit looks like:
- Threat actor list (external attacker, malicious user, malicious insider, supply chain compromise).
- Attack surface map (prompt input, RAG corpus, tool catalogue, agent memory, model supply chain).
- For each (actor, surface) pair, the OWASP LLM Top 10 or OWASP Agentic Top 10 entries that apply.
The reason this is the one auditors ask about first: every other control downstream depends on it. You cannot test for misuse you have not identified.
MEASURE-2.3 - Test for misuse resistance
Once the threat model is on paper, MEASURE-2.3 asks for evidence that the system has been tested against it. Adversarial scans count; single-shot pentests count for the engagement period but not afterwards; continuous scans count better. Multi-judge consensus on each finding is not required by the text but is the easiest way to defuse a model-risk committee's challenge that the test results reflect a single judging model's bias.
What the auditor actually opens: the test report. They look for a date stamp, a coverage statement against MAP-2.3, and a finding-by-finding record with severity, status, and remediation pointer.
MANAGE-2.2 - Treatment of risks
The audit looks for the workflow between finding and resolution. Was the finding routed to an owner. Did the owner make a decision (mitigate, accept, transfer). Was the decision recorded. Did the underlying issue actually get fixed.
The boring control that beats this one: a ticket system with the finding ID in the title, a status field that maps to the finding's status, and a closing comment that references the next scan run. We see customers try to track this in spreadsheets; it falls apart by the second audit.
The thing NIST asks for that most teams miss
Continuous improvement. Buried in MANAGE-4 and GOVERN-2, but real: NIST expects the AI risk programme to learn from incidents and feed lessons back into MAP. In practice this means a quarterly review meeting where the findings backlog gets read against the threat model, and the threat model gets updated when the findings reveal a category that was not on the map.
Most teams skip this step because it feels procedural. Auditors notice when it has been skipped, because the threat model document has the same date as the policy document, and the policy document is six months old.
How to map this to live evidence
For a team running an AI security posture management platform, the mapping is fairly direct. We use the same six-framework cross-mapping for everyone:
- MAP-2.3 -> OWASP LLM Top 10 baseline + OWASP Agentic Top 10 + custom domain probes.
- MEASURE-2.3 -> scheduled adversarial scans with multi-judge consensus.
- MANAGE-2.2 -> finding lifecycle wired through the existing ticketing system.
- GOVERN -> written policy, named owner, audit log.
The control-mapped PDF export from the AI-SPM platform answers the same auditor question for each of these in one document. Without the platform, the same evidence exists, just scattered across three or four tools.
Where to go from here
If you have not read the actual NIST PDF: do that next, it is shorter than expected. If you have read it and have not done MAP-2.3 yet: that is the first thing to write down, in plain text, in a document with a date stamp. Everything else builds on it.
For the AI-SPM platform view, the compliance page shows the cross-framework overlap and the audit log API is the data plane behind MANAGE-2.2.