Your product has AI features. Does the audit care?

Three questions get asked in this order, and only the third one has a satisfying answer.

Does SOC 2 cover AI features?

Not by name. The Trust Services Criteria do not mention AI, models, or anything adjacent.

They cover the system in the system description. If an AI feature is part of the product, it is part of the system, and the same criteria apply to it as to everything else. CC6 wants logical access controls, and an agent calling a backend is logical access. CC7.1 wants vulnerability detection, and a prompt injection path is a vulnerability.

So the answer is that SOC 2 covers AI features the same way it covers any other feature: implicitly, through the system boundary, and only as strictly as your system description commits you to.

Does ISO 27001 cover it?

Same shape. The ISMS scope statement defines what is covered. Annex A 8.8 on technical vulnerabilities and A 8.29 on security testing apply to the AI surface as much as to the rest.

ISO/IEC 42001 is the AI-specific standard, published in 2023, and it is worth being clear about what it is. It is a management system standard, structured like 27001: policy, roles, impact assessment, data governance, lifecycle. It is about governance of AI systems, not adversarial technical testing of them. A 42001 certificate does not tell a buyer that your agent cannot be talked into reading another customer's data.

That matters because the two get conflated in sales conversations. If the question is governance, 42001 answers it. If the question is whether the AI surface has been tested, testing answers it.

What is actually applying pressure

Enterprise security questionnaires, which have moved considerably faster than any framework.

The questions showing up now are specific and technical:

• What data is sent to model providers, and is it used for training
• Can one customer's data appear in another customer's session
• What actions can the AI take without a human approving them
• What credentials do those actions run as
• Do you test for prompt injection
• What is your data retention with the model provider

None of those come from SOC 2 or ISO 27001. All of them come from a security team that has been told to evaluate an AI vendor and has a list.

The useful observation is that most of these are ordinary security questions wearing new vocabulary. "Can one customer's data appear in another customer's session" is multi-tenancy. "What credentials do those actions run as" is least privilege. A company with good answers to the underlying questions has good answers here, and a company without them has a new surface exposing old gaps.

What to do about scope

If you are commissioning a test and the product has AI features, name them in scope explicitly rather than assuming the application test covers them. Specifically:

• The content paths that reach the model, including ingested documents and third party API responses
• The tools or functions the model can invoke, and the identity each runs as
• Retrieval and caching, tested across two tenants
• Any action the agent can take that a person would otherwise have approved

That list is short, and adding it to an application test is usually a modest scope increase rather than a separate engagement. The alternative is a report whose scope section does not mention the part of the product that every buyer is currently asking about.

The answer that works

For a questionnaire, the strongest answer is not a policy and not a certificate. It is that the AI surface was in scope of a penetration test, what was tested, and what was found and fixed.

That is the same answer that works for everything else in the report, which is the point: the AI features are part of your system, and treating them as a separate category is how they end up untested.