NIST's page for AI 600-1, the Generative AI Profile of the AI Risk Management Framework, shows it was created on 26 July 2024 and updated on 8 April 2026. NIST describes it as a cross-sectoral companion to AI RMF 1.0 for voluntary use. It is not a SOC 2 document. But if your product now sends customer content to a language model, your SOC 2 scope has to say something about that, and the auditor will ask.
This post is for AI startups and for B2B SaaS teams that added an AI feature after their first report. It covers scoping decisions only. It does not say what any model vendor has or has not attested to.
What's affected
Four parts of a SOC 2 engagement change when an LLM feature touches customer data.
The system description. Management describes services, infrastructure, software, people, processes and data in scope, and lists subservice organizations. A model API that receives customer data is a candidate.
Subservice organizations. Under the carve-out method the report excludes the vendor's controls but you are still responsible for understanding them and monitoring the risk, according to one CPA firm's guidance published in June 2025. Under the inclusive method the vendor's controls are tested as part of your system, which needs the vendor's agreement.
Criteria categories. Security is always in. The same firm's October 2026 guide says to add categories by listening to what customers ask: uptime questions point to Availability, questions about proprietary data point to Confidentiality. Customers sending documents, code or records into an AI feature are asking the second kind.
Change management. The common criterion on changes expects them to be authorized, tested and approved before production. A model version swap or a system prompt edit changes behavior in production.
How to check if you're exposed
Draw one diagram and answer six questions.
- Which customer data reaches a model? Prompts, retrieved documents, files, metadata?
- Which vendors receive it? Model provider, vector database, hosting, logging, evaluation tools.
- What do contracts say about retention and training on your inputs? Is that written down anywhere an auditor can see?
- Where are prompts and outputs logged, who can read the logs, and for how long?
- Who can change a system prompt, model name or temperature in production, and where is that change recorded?
- Does each vendor have an independent report, and does it cover the service you actually call?
If an answer is "I think so," it is not yet evidence.
What to do now
- Add every AI vendor that receives customer data to your vendor register, with data touched, criticality, report type and period, and review date.
- Decide carve-out or inclusive per vendor with your auditor. Carve-out is the usual choice, but then you need monitoring: read the vendor's report if one exists, note which complementary controls you assume the vendor performs, and write down what you do for the gaps.
- Map user-side responsibilities. If the vendor expects you to configure retention or access settings, those are controls you own.
- Treat prompts and model identifiers as code. Keep them in version control, require review, and link each production change to a ticket or pull request.
- Define what you promise customers about AI data handling and make your report and your marketing say the same thing.
- Decide whether Confidentiality belongs in scope. If customers keep asking about proprietary data, it probably does.
- Use the NIST profile as a reading list for your risk register: it is voluntary guidance, so cite it as a source for risks you identified, not as a requirement you are meeting.
How to avoid this trap
- Do not describe the AI feature in sales material more broadly than the system description covers.
- Do not leave prompt logs in an unmanaged tool. If logs contain customer data, that tool is a vendor and a data store.
- Do not change the model behind a feature outside your normal change process.
- Do not assume the model vendor's report covers your configuration. Check which services and regions it names.
- Do not wait for fieldwork to discover that no one owns the AI vendor review.
Why it matters
Auditors test the system as you describe it. A new vendor in the data flow that is missing from the description is a gap between the description and reality, and that is exactly the sort of thing a Type 2 examination surfaces.
The scoping choice also shapes how your customers read the report. A customer sending sensitive documents into your AI feature will check whether the report mentions the feature, the model vendor and the data handling. Say so plainly and your next security review gets shorter.
Try it yourself
Open your risk register and add three rows: model vendor outage, customer data retained longer than promised by an AI vendor, and an unreviewed system prompt change that exposes data. Give each an owner and a date.
Click through it at your own pace, or open it full screen.
Quick check
Does carving out a model vendor remove your responsibility for it?
No. Under carve-out the vendor's controls are excluded from testing, but management must still understand the vendor and monitor the risk it creates.
Is NIST AI 600-1 a SOC 2 requirement?
No. It is voluntary NIST guidance that complements the AI RMF. SOC 2 is measured against the AICPA Trust Services Criteria.
