Quick answerWhen a customer's SOC 2 (or equivalent) audit reaches you as their AI agent vendor, their auditor is testing your customer's control environment, which means they need evidence that your customer has effective oversight of you as a subprocessor — not a general assurance that your own company is secure. Have ready, before the request comes in: your own current SOC 2 report or equivalent attestation to hand over directly, a data flow diagram showing exactly what customer data your agent touches and where it goes, evidence of the access controls and encryption in place for that data specifically, and a named contact who can respond to auditor follow-up questions within the timeline your customer's audit requires, since a slow response from you becomes a finding against your customer, not just an inconvenience for you.
Why this is a different obligation than your own compliance posture
Which compliance frameworks actually apply to your AI agent and what records you need ready when a regulator wants to audit your AI agent's decisions are both about your own company's compliance obligations, satisfied on your own timeline, to your own regulators or your own attestation cycle. This is about what you owe someone else's audit of you: your customer's auditor doesn't care about your general compliance posture in the abstract — they care specifically about whether your customer has an effective vendor-management control over your relationship, and they need artifacts from you to test that control, on your customer's audit timeline, not yours.
The four artifacts auditors actually ask for
First, your own attestation report (SOC 2 Type II, ISO 27001 certificate, or equivalent) — if you don't have one, be ready to explain what compensating evidence you can provide instead, because "we're working on it" without a concrete artifact is the answer most likely to become a finding against your customer. Second, a data flow diagram specific to what your AI agent actually does with their data: what's collected, where it's processed, where it's stored, how long it's retained, and whether any of it touches a further subprocessor of your own. Third, evidence the access controls you claim are actually enforced — not a policy document describing intended controls, but logs or configuration exports showing they're active. Fourth, a named, responsive contact — auditors work on fixed timelines, and an unanswered evidence request from a vendor is one of the most common reasons a customer's own audit slips its deadline.
Your own subprocessors become part of this too
If your AI agent relies on its own subprocessors — a model provider, a hosting platform, a third-party evaluation tool — your customer's auditor may ask how you've done due diligence on your own vendor's subprocessors, because your customer's control isn't just over you; it extends, at one remove, to whoever you rely on. Keep your own subprocessor list current and be ready to share it (or a summary of your due diligence over it) as part of responding to a customer's audit request, since "we don't track that" is a materially worse answer than having an incomplete but honest list.
Build a standing audit-response package, don't rebuild it each time
If more than one or two customers require SOC 2-adjacent evidence from you as a vendor, build a standing package (attestation report, data flow diagram, access control summary, subprocessor list) that's refreshed on a fixed cadence rather than assembled from scratch under each customer's specific deadline. This turns a recurring fire drill into a predictable maintenance task, and it materially shortens your response time on the requests that do carry a hard external deadline.
FAQ
What if we don't have our own SOC 2 report yet? Be upfront about it and offer the strongest compensating evidence available — a completed security questionnaire, penetration test results, or documented internal controls. Customers can sometimes work around a missing formal attestation with enough alternative evidence, but silence or vague reassurance is the outcome most likely to fail their audit.
How fast do we need to respond to an evidence request? As fast as your customer's audit timeline requires, which is usually far shorter than your own internal review cycles assume — ask for the specific deadline immediately rather than assuming you have the weeks you'd normally take for an internal request.
Does this apply even if we're a small subprocessor with limited data access? Yes, proportionally — the depth of evidence expected scales with how much and what kind of data you touch, but even a vendor with narrow access is still in scope for the customer's control testing if any customer data flows through your agent at all.