You have embedded a third-party voice agent in your product. The first enterprise prospect sends a security questionnaire, and section four asks you to list every sub-processor, where each one stores data and how long it keeps it. The honest answer starts with your voice vendor, and you don't have its documents yet.
This guide is for the SaaS or telecom product team that owns that questionnaire. It maps the questions your customers are likely to ask about an embedded voice vendor to the evidence you need from that vendor, so you can close the gaps before the first enterprise deal, not during it. It is general information, not legal advice; contract and data-protection questions go to your counsel.
Your customers review you, not the vendor
Your customer signs with you. It may never see the voice vendor's name until it appears in your answers. From then on, the vendor's controls are part of your product as far as that customer is concerned.
Where your product processes personal data for your customers, the voice vendor can be a sub-processor in your chain. In the UK, Article 28 of the UK GDPR says a processor may not engage another processor without the controller's prior written authorisation. Under a general authorisation, the processor must tell the controller about intended changes so it can object. The same data-protection obligations must flow down to the sub-processor, and the first processor stays fully liable for it. Article 28 of the EU GDPR sets the same sub-processor rules for the EU. Which text applies, and whether these roles fit your set-up, is for your counsel to confirm.
Whatever law applies, the practical step is the same: you need the vendor's evidence before your customer asks, and a way to learn about vendor changes early enough to pass them on.
Ten questions to expect in an enterprise security questionnaire
Customers use their own forms or standard ones, such as the CSA's CAIQ, a set of yes/no questions about a cloud provider's controls. Whatever the format, prepare for these ten questions about an embedded voice feature. For each one, decide who answers: you, the vendor, or both.
| Your customer asks | Who answers | Evidence you need from the vendor |
|---|---|---|
| 1. What data does the voice feature create (audio, transcript, summary, metadata)? | Both | Data-flow description for your configuration |
| 2. Where is each item processed and stored? | Vendor, passed through by you | Location per data class and per processing step |
| 3. How long is it kept, and who can delete it, including backups? | Both | Retention settings, deletion process |
| 4. Who are the sub-processors, and how are changes notified? | Vendor, passed through by you | Sub-processor list and change-notice terms |
| 5. Is our data used to train models? | Vendor | Written statement in the contract or data processing agreement (DPA) |
| 6. Which security reports or certificates cover the service? | Both | Report or certificate, with holder, scope, type and date |
| 7. How is data encrypted in transit and at rest? | Vendor | Security documentation |
| 8. Who can access recordings, including vendor support staff? | Both | Access-control and support-access description |
| 9. How fast will we hear about an incident? | Both | Incident-notice terms |
| 10. What happens to calls when the voice service is down? | You | Vendor availability terms; your own fallback design |
The list follows the procurement questions in our voice AI security guide, turned around: there you ask a vendor for your own use; here you answer for a product your customers buy from you.
Turn the table into an answer library before the first questionnaire arrives. For each question, keep one approved answer, the document it rests on, that document's date, and the person who signed the answer off. Mark every answer that depends on the vendor. When the vendor changes a sub-processor, a region or a retention default, those are the answers to re-check, and the mark tells you which ones they are.
"Both" means two answers in one. For question 8, you describe who on your team can open recordings and why; the vendor's part covers its own support staff. Write them as two labelled parts, so a reviewer can see where your control ends and the vendor's begins.
Two questions deserve extra care. On model training (question 5), take the answer from the contract or DPA, not from a marketing page or a sales email. On outages (question 10), the answer is yours even though the cause may be the vendor's: your customer wants to know what their callers experience, not whose system failed.
When a vendor-dependent answer is not confirmed yet, do not write "N/A" or leave the cell blank. Write what is pending, from whom, and by when you expect it. An open item with an owner is easier for a reviewer to accept than a guess that unravels later.
Evidence you need from the voice vendor (and what NDAs allow you to share)
Ask for the documents before the first enterprise deal, not after the questionnaire arrives:
- the security report or certificate, with the exact legal entity, scope, type and date;
- a DPA with a sub-processor annex and the change-notice clause;
- a data-flow description for the configuration you actually use;
- retention and deletion settings, including who can change them;
- incident-notice and availability terms.
Read each badge before you repeat it. A certificate held by one legal entity for one scope is not a statement about every product that entity's group sells. Here is how we would describe NextLevel's own evidence: a "SOC 2 Type I report (point-in-time, 28 Aug 2025, NextLevel.ai Agentic Platform, under NDA)" and an "ISO/IEC 27001:2022 certificate held by SPsoft (Inc/FZE/LLC), scope software-development services". The second one is held by the parent company and its scope is software-development services, not the voice platform as such, so presenting that certificate as covering the voice platform would overstate it. NextLevel's compliance page describes a Type 1 report as assessing the design of controls at a specific point in time. If a question asks how controls operated over a period, say which report you have and its date, and let the customer decide.
Reports like these are often shared only under a non-disclosure agreement (NDA); NextLevel's SOC 2 report is one. An NDA can stop you forwarding the report itself to your customers, so read its terms. Ask the vendor in writing what you may say about it, whether it will share the report with your customers directly under their own NDA, and who answers their follow-up questions. Keep a register of what you received: document, version, date, NDA status and who inside your company may see it.
Data locations, retention and sub-processors: answering without overclaiming
Answer per data class and per step, not with one country name. Audio, transcripts, summaries, metadata and logs can each live in a different place for a different time. "Stored in the EU" says nothing about where speech is processed, where a model runs or what support staff can open. Our data residency and retention guide covers the vendor-side questions in detail.
Be exact about what is listed and what is not. NextLevel's pricing page lists four deployment zones: US, EU, UAE and KSA. A UK customer asking for UK-only storage gets a straight answer: no UK zone is listed, and whether the EU zone is acceptable is that customer's decision.
Filled example (fictional): a field-service scheduling platform answers one questionnaire section about its embedded voice feature.
| Question | Draft answer | Evidence held | Gap |
|---|---|---|---|
| Where are call recordings stored? | "In the vendor's EU zone, per our configuration." | Vendor DPA annex | Speech-processing location not yet confirmed |
| How long are transcripts kept? | "Set by us; currently 30 days (fictional)." | Our admin setting | Vendor backup handling unknown |
| List sub-processors | "See attached list (voice vendor and its listed sub-processors)." | Vendor list, dated | No change-notice clause signed yet |
Leave a gap visible rather than writing a smooth answer you cannot support.
For sub-processors, keep the vendor's list with its date, and record each entry's function and location next to your own list. The change-notice clause matters more than the list. If your customers have a right to object to new sub-processors, they need notice before the change takes effect, and you can only give it if the vendor gives it to you first, with time to spare. Agree that notice path with the vendor in writing.
For retention, say who controls each setting. If you set transcript retention in an admin console and the vendor sets backup retention, the questionnaire answer needs both, with the owner named for each.
Uptime and incident terms you can pass through
Promise your customers only what you receive. If the vendor's availability or incident-notice terms are weaker than what your customer wants, you either negotiate them up or design your product so the voice feature can fail without breaking your own commitment.
Three checks keep the chain consistent:
- Availability. Compare the vendor's terms with what you offer. NextLevel's pricing page lists "Custom SLAs" (service-level agreements) for enterprise contracts; the actual terms are whatever the contract says.
- Incident notice. Your notice to customers can only start after the vendor tells you. Subtract your own handling time.
- Fallback. Decide what callers get when the voice feature is unavailable, such as a route to a person or a message, and state it. A clear fallback lets your own terms say what happens during a vendor outage instead of leaving it open.
Before the first enterprise deal, confirm you hold: the vendor's report or certificate with its five fields recorded; the signed DPA and sub-processor list; a change-notice path into your own customer notices; and availability, incident and fallback terms written into your contract.
Where NextLevel fits
NextLevel's compliance page lists the security documents available to current and prospective clients on request, under NDA where applicable. The partner programme names SaaS platforms that embed voice and chat; embedding terms are confirmed in scoping.
Next step: request the documents listed on the compliance page, then discuss embedding on a scoping call, booked from the pricing page.
Frequently asked questions
Is the voice vendor our sub-processor?
It can be, where it processes personal data on your customers' behalf. Your counsel confirms the roles for your contracts.
Can we send the vendor's security report to our customers?
Only as its NDA allows. Ask the vendor what you may share and whether it will share the report with your customers directly.
What if our customer needs data kept in the UK?
Check the vendor's listed zones. If no UK zone is listed, say so; whether another zone is acceptable is the customer's call.
Does the vendor's report cover our product?
No. It covers the vendor's scope. Your customers will still review your own controls, from access to your admin console to how you handle their data.
Sources
- UK GDPR Article 28, legislation.gov.uk, read 9 Nov 2026: paragraphs 2 and 4.
- EU GDPR, Regulation (EU) 2016/679, Article 28, EUR-Lex, read 9 Nov 2026: paragraphs 2 and 4.
- CSA STAR Level 1 Security Questionnaire (CAIQ v4.1), read 9 Nov 2026.
- NextLevel compliance page, document list, SOC 2 Type I description and its description of a Type 1 report, read 9 Nov 2026.
- NextLevel pricing page, enterprise block (deployment zones, custom SLAs), read 9 Nov 2026.
- NextLevel partner programme, read 9 Nov 2026.