Audit firms increasingly rely on third-party AI tools for research, document review, drafting, analytics, and other professional work. The vendor may provide the interface, while another company provides the model, cloud infrastructure, or data storage behind it.
That makes vendor due diligence an important part of AI governance. The goal is not simply to ask whether a provider is "secure." Audit firms need to understand what the tool does with client information, how reliable it is for the intended use, which third parties are involved, and what happens when the product changes.
1. What exactly are we approving the vendor to do?
Start with the use case rather than the vendor name.
Will the tool summarize public accounting guidance, process audit working papers, analyze client transactions, draft engagement documentation, or connect to an internal repository? A product that is acceptable for public research may require much stronger controls before it receives confidential engagement data.
PCAOB staff reported that firms they contacted were primarily using generative AI for administrative and research activities, while many were also considering uses in planning and performing audits. Firms also highlighted the need for strong supervision around data privacy and security.
Approval should state which uses are permitted, which data categories are allowed, and which uses require additional review.
2. What happens to prompts, files, and outputs?
Ask the vendor to explain the complete data lifecycle.
Useful questions include:
- Are prompts and uploaded files retained?
- How long are they retained?
- Is customer content used to train or improve models?
- Can retention be configured?
- Where is information processed and stored?
- Who can access it?
- What happens when data is deleted or the contract ends?
IESBA's current technology guidance emphasizes that confidentiality applies across the full data lifecycle, including collection, use, transfer, storage, dissemination, and lawful destruction. It also notes that using client data for purposes such as AI model training requires proper authorization.
The firm's contract should match the vendor's answers.
3. Which third parties are behind the product?
The company selling the product may not be the only organization processing audit-firm data.
Ask which model providers, cloud platforms, subprocessors, and other third parties participate in the service. Determine what information each party receives and whether the vendor will notify the firm when important subprocessors change.
NIST's Generative AI Profile identifies third-party generative AI integrations as an area requiring additional risk management and is designed to help organizations manage risks associated with generative AI products and services.
The practical question is whether the full supply chain is understood well enough for the intended client data.
4. How has the vendor tested reliability?
Security controls do not make AI output reliable.
Ask how the provider evaluates accuracy, known limitations, failure modes, and changes between model versions. Request evidence relevant to the actual use case rather than relying only on broad benchmark claims.
If the system will assist with professional work, determine whether outputs can be traced to source information and independently checked.
IESBA states that professional accountants using technology outputs should assess fitness for purpose, understand limitations and assumptions, evaluate data quality and potential bias, and determine the appropriate extent of reliance. Professional responsibility remains with the accountant.
5. What security and access controls are available?
Review the controls that matter in the firm's environment.
These may include single sign-on, multi-factor authentication, role-based permissions, audit logs, administrative controls, user provisioning, encryption, and restrictions on integrations.
Ask whether the firm can prevent employees from enabling unapproved connectors or features. A system connected to a document repository may expose substantially more information than the same product used only through manual prompts.
The principle should be least privilege: the AI tool receives only the access required for the approved task.
6. How does the vendor handle incidents?
Ask what happens when something goes wrong.
How quickly will the vendor notify the firm about a security incident? What information will it provide? Can it identify which customer data was affected? Are useful logs available for investigation?
The firm's incident-response process depends partly on what evidence the vendor can provide. Vague notification commitments may not be enough for a high-risk audit workflow.
7. How are material product changes communicated?
AI products can change quickly after approval.
A vendor may replace the underlying model, introduce persistent memory, add agent capabilities, change retention practices, or connect to new services. IAASB's Technology Quality Management Workstream is examining how firms apply quality management standards to AI-driven and other emerging technologies used in audit and assurance engagements.
IAASB's global roundtables have also highlighted governance and risk management as important issues as AI-enabled tools become more integrated into professional work.
Ask which changes trigger customer notification and whether the firm can delay or disable new features until they are reviewed.
Approval should not become permanent simply because the vendor passed due diligence once.
8. What happens when the relationship ends?
Ask whether the firm can export necessary records, how customer data is deleted, whether backups remain, how long residual copies persist, and how integrations and user access are removed.
The contract should establish what happens to client and firm information when the service is terminated.
Turn the answers into an approval decision
A vendor questionnaire is useful only if the answers affect the decision.
For each proposed AI tool, document the intended use, data involved, major risks, vendor controls, contractual protections, required firm controls, approval owner, and reassessment triggers.
A low-risk research tool may require a lighter process. A system that processes confidential working papers or influences audit procedures should receive deeper technical, privacy, quality-management, and legal review.
AI vendor due diligence for auditors is ultimately about knowing what sits between the engagement team and the technology. If the firm understands where the data goes, who handles it, how the system is tested, what controls exist, and how changes are managed, it can make a reasoned decision about where the tool belongs in audit work.
Vendor due diligence establishes the boundaries of an approved tool, but it cannot supervise every prompt an engagement team submits under deadline pressure. Once a working paper or a client's confidential transaction detail is sent to an AI tool, it cannot be recalled, no matter what the vendor's retention settings promise. This is the principle Sanitized Ai is built on: sensitive engagement data should be caught and redacted before a prompt ever reaches the tool, so that the answers a vendor gives about retention and subprocessors govern far less confidential information in the first place.
This quarter, take one approved AI tool and walk a real audit workflow through it end to end, noting exactly which client data categories a team member could paste or upload before any vendor control takes effect. That exercise usually shows where due diligence answers stop mattering and where a pre-submission control has to carry the weight. If you would like to see how that control works against your own audit use cases, request a demo.