A single compliance audit can halt a 500-agent contact center operation overnight. The vulnerability is rarely your telephony stack. It is your speech-to-text vendor's data training policy, hosting region, and security controls, and whether those controls hold up when your legal and procurement teams start the RFP review.
Contact centers are automating QA workflows at scale, which means routing exponentially more sensitive customer voice data through third-party transcription infrastructure. The compliance question is no longer theoretical. It is an operational variable that directly affects your QA coverage rate, your audit posture, and your cost-per-contact.
How security standards protect CX operations
Accurate transcription is the foundation for every downstream system in your operation: QA scorecards, CRM entries, coaching data, and compliance reporting. When the transcription layer operates outside compliant boundaries, errors cascade silently. A wrong name enters a CRM record, a missed entity produces a misleading coaching score, and a non-compliant data flow surfaces during a regulatory audit rather than during implementation.
Certification alone does not protect downstream systems if the transcription itself is inaccurate. A vendor can be fully SOC 2 Type II and ISO 27001 certified while still producing transcripts that corrupt QA scorecards, misattribute agent speech, or fail to capture key entities in accented or multilingual calls. That is why compliance-critical contact centers should evaluate accuracy on production audio, not clean studio recordings. Solaria-1 is benchmarked across 74+ hours of real-world conversational audio against 8 providers, delivering on average 29% lower WER on conversational speech and 3x lower DER vs. alternatives, which are the same conditions your compliance reporting depends on.
For European business and contact-center audio specifically, Solaria-3 ranks #1 across English, French, German, Spanish, and Italian against AssemblyAI, ElevenLabs, Deepgram, Mistral, and Speechmatics on real customer recordings.
Audit trail standards for contact centers
Your transcription vendor must maintain an immutable audit log documenting who accessed, transcribed, modified, or deleted a call recording and when. Under GDPR, SOC 2, and ISO 27001, the inability to produce a complete data access log during a regulatory review is not a minor gap; it is a material control failure. Vendor data retention and deletion policies must align with your own documented retention schedules, and those policies must be visible in the contract. Our data retention policies andcompliance pagedetail these controls explicitly.
How cross-border data flows impact QA
Business Process Outsourcing (BPO) operations in Southeast Asia, South Asia, and Latin America generate call audio in regional languages and dialects. Routing that audio to a transcription API that processes exclusively in the US executes a cross-border personal data transfer that triggers GDPR adequacy requirements or standard contractual clauses for EU-originated data. Beyond the legal exposure, WER degrades with accented speech on providers built primarily for American English, so QA scores and coaching data built on those transcripts will be unreliable. For operations running agents who speak Tagalog, Bengali, Tamil, or Urdu, the language coverage gap compounds both the compliance and accuracy problems simultaneously. We support 100+ languages including 42 not covered by other APIs, all processed within the same GDPR, SOC 2 Type II, ISO 27001, and HIPAA-certified infrastructure, so expanding language coverage does not expand your compliance surface.
Managing vendor compliance risk
The shared responsibility model applies directly to STT APIs. Your transcription vendor secures the API infrastructure, encryption, and data handling. You remain accountable for user consent, jurisdictional compliance, downstream access controls, and vetting your sub-processors. If your STT vendor fails a SOC 2 audit, the breach is yours to report.
Ensuring GDPR compliance in voice analytics
Voice recordings containing identifiable information about an individual are generally treated as personal data under privacy regulations. The definition typically extends to biometric data when processed by voiceprint or speaker identification systems for the purpose of uniquely identifying an individual. A voice recording capturing speech content qualifies as personal data at minimum. It escalates to special-category biometric data when processed by such systems.
Non-compliance carries direct financial risk. GDPR violations can result in substantial fines for failures in data processing lawfulness, inadequate security measures, and unlawful cross-border transfers, all of which are implicated when a contact center uses an uncertified or inappropriately hosted STT vendor for EU call audio.
Essential GDPR rules for AI vendors
Before any EU call audio flows through a transcription API, a signed Data Processing Agreement (DPA) must be in place. The DPA must specify the purposes for processing data, the security measures in effect, the data retention schedule, and whether the vendor uses audio for model training. Vendors that train models on customer audio by default without a clear opt-out mechanism process personal data beyond the original purpose of the transaction, which constitutes a GDPR violation.
EU hosting for compliance
US-only hosting creates a cross-border transfer problem for EU call audio that requires an adequacy decision or standard contractual clauses to resolve, and both carry ongoing regulatory risk. We are headquartered in Paris and by default process and store data within the EU, eliminating the need for transfer mechanisms on EU-originated audio. We also operate clusters in the US, so North American operations get regional processing without routing audio across the Atlantic. Multiple regional processing options are available, with on-premises and air-gapped deployment options for organizations with stricter data residency requirements.
Protecting your CCaaS data pipeline
Encryption standards for audio in transit and at rest, plus explicit documentation of those standards, are baseline requirements for processing personal data under GDPR. Verify these in your vendor's security documentation rather than assuming them. We document our security controls in our compliance documentation. On the Starter plan, audio can be used for model training by default. On Growth and Enterprise plans, that default is inverted: customer data is never used for model training, and no contract clause negotiation is required.
"It's based in EU so it fits our GDPR compliance requirements... The product works great. They're improving the product continuously." - Robin L. on G2
SOC 2 Type II: proving operational security
SOC 2 Type II verifies that the vendor operated those controls effectively over a defined period. For CCaaS procurement, Type II is the minimum acceptable standard because it addresses the operational reality that controls exist on paper but sometimes fail in production. A vendor holding only a Type I report has passed a design review, not a performance audit.
SOC 2 vs. ISO 27001
These certifications are complementary, not interchangeable. The table below summarizes the key distinctions as defined by AICPA SOC 2 standards and ISO/IEC 27001 requirements:
| Dimension |
SOC 2 Type II |
ISO 27001 |
| Scope |
Specific systems or services |
Defined ISMS boundaries (can include full organization or specific departments) |
| Focus |
Trust services criteria (security, availability, confidentiality) |
Information security risk management |
| Audit frequency |
Annual attestation |
Annual surveillance audits with full re-certification every three years |
| Primary utility for CCaaS |
Validates that STT API controls worked in practice over time |
Validates that the vendor's security management system is governed and maintained |
As Sprinto's comparative analysis notes, SOC 2 dominates North American vendor evaluation cycles while ISO 27001 is the globally recognized standard. Both should appear on your vendor qualification checklist for cross-border contact center operations.
SOC 2 controls for call data security
Your STT vendor's SOC 2 report must include specific controls in scope: encryption of audio in transit and at rest, multi-factor authentication (MFA) on all administrative access to call data, role-based access controls preventing unauthorized engineer access to production audio, intrusion detection and monitoring, and incident response procedures with defined notification timelines. Request the full Type II report from your vendor, because a summary letter is not sufficient for enterprise procurement or regulated industry audits.
Operationalizing SOC 2 for CCaaS
Map your vendor's controls to your own operational calendar: confirm their audit period covers your go-live date, verify that their subprocessors are also covered, and schedule the next renewal so your compliance team isn't caught with an expired report during an internal audit. We hold active SOC 2 Type II certification.
Managing ISO 27001 requirements in CCaaS deployments
ISO 27001 certifies that an organization has established, implemented, maintained, and continuously improved an Information Security Management System (ISMS) across its operations. Unlike SOC 2, which evaluates specific service controls, ISO 27001 governs how the vendor manages security risk as an organization-wide function. For Contact Center as a Service (CCaaS) platforms operating in multiple jurisdictions, this means the vendor's security posture extends through their hiring, access management, incident response, and supplier management processes, not just their API endpoint.
ISO 27001 audit requirements explained
Maintaining ISO 27001 certification typically requires continuous risk assessments, internal audits, and management reviews, along with periodic external audits to verify ongoing compliance. When vetting an STT vendor, ask for their most recent certificate with issue and expiry dates, their Statement of Applicability listing the controls implemented and any exclusions, and their most recent internal audit summary. Vendors who cannot produce these documents on request have likely let their certification lapse or obtained it solely for procurement purposes.
Data breach protocols for compliance
Privacy regulations typically require you to notify your supervisory authority within a short timeframe of discovering a personal data breach involving EU resident data. Your STT vendor must contractually commit to notifying you of any breach involving your audio data within a timeframe that allows you to meet that window. This commitment must appear in the DPA, not as a verbal assurance. ISO 27001 compliance typically mandates documented incident management procedures, so verify that your vendor's ISO 27001 scope includes their data handling and notification processes.
HIPAA requirements for healthcare voice analytics
Healthcare contact centers processing member services calls, care coordination inquiries, or billing support handle Protected Health Information (PHI) in every interaction. Transcription vendors that receive, create, maintain, or transmit PHI on your behalf are typically classified as Business Associates under HIPAA, and that classification triggers mandatory legal and technical requirements before any audio is processed.
What HIPAA requires from transcription vendors
The four non-negotiable requirements for any transcription vendor handling healthcare call audio are:
- Encryption: Applied to all audio files and resulting transcripts, both in transit and at rest, verified in writing.
- Access controls: Role-based access with multi-factor authentication on systems that touch PHI, plus comprehensive audit logging.
- Audit logs: Immutable records of who accessed, processed, or deleted PHI, retained for a minimum of six years under HIPAA regulations.
- Signed Business Associate Agreement (BAA): A signed BAA is a legal prerequisite before disclosing any PHI to a vendor. The BAA must define permitted uses of PHI, security obligations, breach notification timelines, and requirements for the vendor's own subprocessors.
BAA requirements for transcription
A BAA is the legal instrument that makes your vendor a contractual extension of your HIPAA compliance program. If your STT vendor processes healthcare call audio without a signed BAA, you are in violation regardless of any other security controls in place. Both the covered entity and the Business Associate carry independent liability for violations. When requesting a BAA from an STT vendor, verify that it covers their subprocessors and includes specific breach notification timelines. We support BAA execution for healthcare customers and maintain HIPAA compliance.
Securing PHI in speech data
Our PII redaction feature can detect and replace medical terms, names, and numbers in transcripts with labeled placeholders such as [NAME] or [PHONE_NUMBER]. This must be explicitly enabled in the API request configuration and does not activate by default on any plan. For healthcare contact centers, enabling PII redaction at the transcription layer limits PHI propagation to CRM systems, coaching dashboards, and QA scoring platforms. For operations needing the strongest possible data boundary, we support on-premises and air-gapped deployment to prevent PHI from leaving organizational infrastructure entirely.
PCI DSS requirements for transcription vendors
Payment support calls often capture sensitive cardholder data including Primary Account Numbers (PAN), CVV codes, expiration dates, and cardholder names. Storing any of these in unredacted call recordings or transcripts can create PCI DSS compliance issues. PCI DSS compliance frameworks require systems handling cardholder data to implement controls to detect and remove sensitive payment data from voice recordings before that data reaches analytics, CRM, or QA systems.
PCI DSS compliance for audio data
For transcription pipelines processing payment calls, PCI DSS frameworks typically require that cardholder data not be retained after authorization unless there is a documented, justified business need. In practice, your STT vendor must either redact PAN and CVV data at ingestion or demonstrate that their pipeline is fully within your PCI DSS scope and compliant with all applicable controls. Redaction at ingestion is far simpler to audit and maintain.
PCI DSS data masking requirements
When explicitly enabled in the API configuration, our PII redaction feature identifies and replaces sensitive identifiers. The key operational benefit is that redaction is designed to occur within the transcription pipeline, before data reaches your CRM or QA platforms, keeping cardholder data out of systems that were never designed to be PCI-scoped. The speaker diarization feature is also worth configuring for payment call contexts, since identifying which speaker segment contains the card data can allow more precise redaction targeting and reduce false positives on agent-side references to payment processes.
How our certifications compare to US-only STT vendors
The practical compliance gap between us and US-centric STT vendors comes down to three variables: where data is hosted by default, whether model training on customer audio requires an opt-out, and which certifications are active versus pending.
EU hosting for regulated transcription
Our default processing region is France, using a European hosting provider. EU call audio stays within the EU without requiring adequacy decisions, standard contractual clauses (SCCs), or supplementary measures. Other major STT vendors offer regional processing options, but their default configurations and primary infrastructure are typically US-based, which means EU-specific data residency requires deliberate configuration and ongoing verification rather than being the baseline. For contact centers with BPO operations in EMEA, our EU-default configuration reduces cross-border transfer complexity from the outset.
Deployment model comparison
| Dimension |
Cloud API (Gladia EU-default) |
Self-hosted open-source |
| Data residency |
EU or US, configurable |
Wherever you host it |
| Certification coverage |
SOC 2 Type II, ISO 27001, HIPAA, GDPR |
Typically none (your responsibility) |
| WER in production |
6.4% WER on Earnings22 financial calls |
10%+ reported on contact center audio |
| Model training on data |
Never on Growth/Enterprise |
N/A |
Teams that self-host open-source models to keep data internal trade vendor compliance risk for operational risk: no certifications pass through to their deployment, DevOps overhead can consume substantial engineering capacity, and the accuracy gap is measurable. Solaria-3 reaches 6.4% WER, the only model under 7% in that benchmark, while self-hosted open-source models on comparable real-world business audio typically land well above that threshold.
Must-have certifications for CCaaS vendors
Use this checklist when shortlisting any STT vendor for a regulated CCaaS deployment:
- GDPR: Signed DPA, EU-hosted processing option, no model training on customer audio by default on paid plans
- SOC 2 Type II: Active report (not Type I only), covering the production API and associated data handling
- ISO 27001: Active certificate with current surveillance audit date and Statement of Applicability available on request
- HIPAA: BAA available before any PHI is processed, Business Associate classification accepted in writing
- PCI DSS: Documented cardholder data redaction at ingestion, pipeline scoped or excluded from cardholder data storage, and redaction configuration demonstrable before production deployment We hold GDPR, SOC 2 Type II, ISO 27001, HIPAA certifications.
Transcription security: essential vendor questions
The 6-to-18-month RFP cycle for contact center platforms means your compliance team will spend significant bandwidth evaluating vendors. These questions separate compliant audio infrastructure from vendors who hold certification documentation but haven't operationalized the controls.
Audit steps for transcription vendors
A structured evaluation should cover these stages:
- Documentation request: Ask for the SOC 2 Type II report (full, not a summary), ISO 27001 certificate with expiry date, Statement of Applicability, BAA template, DPA template, and data retention policy.
- Hosting verification: Confirm the specific cloud regions where audio is processed and stored. Get written confirmation that EU call data will not leave EU infrastructure without your explicit authorization.
- Model training policy: Request the training policy in writing, specifying which plans are covered and whether the default is already off or requires an opt-out.
- PII and PCI controls: Request a live demonstration of redaction configuration. Verify that redaction operates at ingestion, not post-processing after cardholder data has already been written to a transcript.
- Incident response: Ask for the contractual breach notification timeline and verify it gives you enough lead time to meet your GDPR 72-hour reporting obligation.
- Subprocessor list: Request the list of subprocessors with their own certification status. Your STT vendor's SOC 2 is only as strong as the infrastructure it runs on.
Compliance-ready audio infrastructure is not a line item to optimize away during vendor selection. When transcription operates outside certified boundaries, every downstream system from QA scoring to CRM population inherits the failure. Get started with our Starter planand have your integration in production in less than a day, or test us on your own contact center audio to see how Solaria-3 handles business calls, noisy recordings, and accented European speech, or Solaria-1 for broader language coverage and code-switching.
FAQs
Is voice recognition biometric data under GDPR?
Yes. Under GDPR Article 4, voice recordings are personal data if they contain identifiable information about an individual. They escalate to special-category biometric data when processed using specific technical methods, such as voiceprint analysis or speaker identification, for the purpose of uniquely identifying a natural person. Contact center call recordings typically qualify as personal data at minimum, and any speaker diarization or voice identification layer pushes them into biometric data territory, triggering stricter processing requirements.
What is the difference between SOC 2 and ISO 27001 for transcription?
ISO 27001 certifies that the vendor has an ISMS governing their entire organization's information security risk management, while SOC 2 Type II specifically audits whether the security controls for a defined system or service operated effectively over a period of 6 to 12 months. For CCaaS procurement, you need both: SOC 2 confirms the production API controls work in practice, and ISO 27001 confirms the broader organizational security posture is governed and maintained.
Does Gladia use customer audio to train its models?
On the Starter plan, data can be used for model training by default. On Growth and Enterprise plans, customer data is never used for model training and no opt-out action is required. For regulated or sensitive audio workloads, Growth is the minimum tier that provides this guarantee by default. This policy applies as a default on paid plans, not as an enterprise-negotiated clause.
Is PII redaction automatic on Gladia?
No. PII redaction is an optional feature that must be explicitly enabled in the API request configuration. It does not activate by default on any plan. For contact centers processing payment or healthcare calls, enabling redaction at the API level is the correct implementation approach, and it should be tested against your specific call audio types before production deployment.
Key terms glossary
Contact Center as a Service (CCaaS): A cloud-based customer experience solution that enables organizations to manage inbound and outbound customer contact across multiple channels. CCaaS platforms route voice, email, chat, and other interactions through a unified infrastructure, often including analytics, QA, and compliance tools.
Personally Identifiable Information (PII): Any data that can be used to distinguish or trace an individual's identity, such as names, social security numbers, or phone numbers. Under GDPR, PII is a subset of the broader "personal data" classification, which covers any information relating to an identified or identifiable natural person.
Data Processing Agreement (DPA): A legally binding contract between a data controller and a data processor that defines the scope, purpose, and terms of personal data processing. Required under GDPR before any personal data (including voice recordings) is shared with a third-party vendor.
Business Associate Agreement (BAA): A contract required under HIPAA between a covered entity (such as a healthcare provider) and a Business Associate (such as a transcription vendor) that handles Protected Health Information. The BAA defines permitted uses, security obligations, and breach notification requirements.
Protected Health Information (PHI): Any individually identifiable health information protected under HIPAA, including medical histories, test results, and insurance details. Any transcription vendor receiving PHI on behalf of a covered entity is a Business Associate and must sign a BAA before processing begins.
Word Error Rate (WER): The standard metric for measuring speech recognition accuracy, calculated by comparing the transcribed output to a reference transcript. Lower WER means fewer transcription errors, which directly limits error propagation into QA scores, CRM entries, and coaching data downstream.
Diarization Error Rate (DER): The metric for evaluating speaker diarization accuracy, measuring how correctly a system attributes audio segments to individual speakers. High DER in contact center transcription means agent and customer speech is misattributed, which corrupts script adherence scoring and agent coaching data.
