Vulnerability assessment and penetration testing guide
A vendor can add AI to an existing product without changing its name or the contract’s main description. A search assistant, support summarizer, or action-taking copilot can introduce a new data recipient, retrieval system, or permission boundary. An older penetration-test report may not cover that addition.
Establish what was added
Ask the service owner to describe the feature in operational terms: what data it receives, which external services process it, what it retrieves, what it retains, and whether it can take actions. Distinguish an employee using AI internally from a customer-facing feature and from AI embedded in the production workflow.
Update the service inventory with the AI feature, responsible owner, data categories, model or provider, enabled connectors, and deployment date. Where model details cannot be disclosed, request a stable service/version description and a change-notification process. The purpose is to connect evidence to the service in use, not to collect confidential model internals.
Look for changes through authorized business records
During onboarding and renewal, compare product release notes, the vendor’s subprocessor list, privacy and data-use statements, administration settings available to your team, and direct responses from the vendor owner. These sources can reveal a change that an annual questionnaire missed. Marketing language alone does not establish how your tenant is configured.
Ask whether the feature is enabled by default, optional, limited to certain plans, or already processing your organization’s information. Request written clarification of conflicting statements. Do not conclude that AI is absent merely because the vendor has not announced it prominently.
Expand the evidence questions
OWASP’s GenAI risk guidance identifies concerns including prompt injection, sensitive-information disclosure, improper output handling, and excessive agency. For buyers, the practical issue is which data and actions the surrounding application permits, and what controls constrain them.
- Retrieval: how does the service preserve the source system’s user and customer permissions when retrieving information?
- Actions: which tools or integrations can act on the user’s behalf, with what privileges and approval requirements?
- Data handling: what is sent to model providers, retained in logs, or used for training, and under which terms?
- Output handling: how is generated content reviewed before it affects records, decisions, or external communications?
- Change control: which model, connector, configuration, and permission changes prompt reassessment?
Separate AI-assisted testing from testing an AI feature
A testing provider’s use of AI does not establish that the vendor’s AI feature was in scope. Ask separately what tools supported the assessment and which product boundaries were reviewed. If confidential reports or customer information enter a testing tool, establish approved handling, retention, and access conditions.
An assessment should identify the deployed feature and configuration, relevant test conditions, limitations, and material findings. Variable model behavior means one observed response cannot establish how the service behaves in all circumstances. Security evaluation also does not by itself establish factual accuracy, fairness, or suitability for every business decision.
Close gaps before relying on old assurance
Suppose a vendor adds a document assistant after its most recent test. Ask for the change assessment, the new data-flow summary, and evidence covering the assistant’s permissions and integrations. Keep the prior report as evidence about its stated scope, not as implicit approval of the new feature.
Product, security, privacy, and procurement owners should agree on any interim restrictions and remediation plan. Retest material changes to permissions and data handling, record residual limitations, and decide when human review or feature restrictions remain necessary. Use the vendor-review FAQs for the wider assurance discussion.
Sources and scope of this guidance
The questions and examples above are buyer guidance, not a claim that a particular law or assurance standard requires every activity. Match the engagement to your risks, obligations, and written authorization.