Every time an agent manually pauses a recording to take a credit card number, your average handle time ticks upward and your exposure to human error compounds. Across thousands of calls per day, the operational cost of manual compliance workflows materializes quickly, and so does the liability when an agent forgets to resume.
Managing call recording compliance is not primarily a legal problem. It's an infrastructure problem. GDPR, PCI DSS, and HIPAA each impose specific rules on how you capture, store, redact, and delete recorded interactions, and manual processes often struggle to meet what these frameworks require at scale, creating potential regulatory risk. This guide covers each framework in operational terms: what the rules are, where manual workflows break down, and what automated infrastructure at the transcription layer does to close the gap.
Mitigating legal risks in call recording
Before recording begins, you must ensure agents deliver disclosure prompts, consent is valid under the applicable framework, and any sensitive data captured during the call is protected through encryption and automated redaction. The operational tension is real: compliance disclosures and data-handling procedures add seconds to every call, and those seconds compound into measurable AHT increases at scale.
GDPR fines for serious infringements can reach €20 million or 4% of global annual turnover, whichever is higher. HIPAA penalties range from $145 per violation for unknowing violations to $73,011 per violation for willful neglect not corrected, with an annual cap of $2,190,294 for repeated violations of the same type, per HHS's most recent inflation adjustment. Organizations must be prepared to produce recorded calls and demonstrate compliant data handling on request, which means data governance cannot be reactive.
US-based operations face a layered consent landscape that differs by state. EU and UK operations must satisfy the GDPR and UK GDPR respectively. The table below summarizes the key US consent categories.
Table 1: US state consent requirements for call recording
| Consent rule |
States |
Operational requirement |
| One-party consent |
Texas, New York, and most US states |
One party to the call (typically the agent) must consent to the recording |
| All-party consent |
California, Connecticut, Delaware, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, Nevada (for phone calls), New Hampshire, Pennsylvania, Washington |
All parties must be informed and consent before recording begins |
GDPR checklist for recorded customer interactions
Managing consent in recorded calls
GDPR Article 4(11) defines consent as freely given, specific, informed, and unambiguous; Article 7 requires that you can demonstrate consent was given and that data subjects retain the right to withdraw at any time. Passive disclosure (for example, "This call may be recorded") does not satisfy either standard. You typically need an explicit opt-in, which can be delivered through an Interactive Voice Response (IVR) key press, a verbal confirmation captured in the recording, or a digital signature on a consent form before the call begins.
Under earlier UK data protection practice, organisations historically relied on an implied-consent approach in which an audible notification that a conversation was being recorded was considered sufficient. GDPR requires active, explicit consent instead. The table below maps the three consent standards contact center operations regularly encounter.
Table 2: Consent standards comparison for call recording
| Consent type |
Legal definition |
Applicability |
Operational impact on AHT |
| One-party consent |
One call participant (typically the person recording) consents by being part of the conversation |
US (most states) |
Minimal: internal process only |
| All-party consent |
Every participant must be informed and consent before recording |
US (13 states), UK DPA |
Adds disclosure prompt time per call |
| GDPR active/explicit consent |
Freely given, specific, informed, unambiguous opt-in required |
EU, EEA |
Requires IVR or agent-delivered opt-in flow |
Automating GDPR call data deletion
GDPR's right to erasure requires you to respond within 30 calendar days of receiving a deletion request. For contact centers processing thousands of calls daily, manually locating and deleting a specific customer's recordings across primary storage, backup systems, and downstream transcript stores creates operational expense and opens the door to human error.
Our API includes a delete endpoint for pre-recorded transcription jobs, letting compliance teams programmatically remove transcription outputs and associated metadata without manual intervention. The data retention documentation details default retention periods and how to configure custom expiry policies.
EU data residency for call recordings
GDPR restricts the transfer of personal data outside the European Economic Area unless specific adequacy decisions or safeguards (such as Standard Contractual Clauses) are in place. For contact centers handling EU personal data, the transcription and storage pipeline must either remain within EU borders or implement rigorous governance for any transfers outside the EEA, not just the audio capture layer.
Our EU region processes and stores data within the EU by default, and on Growth and Enterprise plans, audio is never used to retrain models, with no opt-out required. This is a default configuration, not a contract clause buried in an enterprise addendum. Starter plan audio can be used for model training by default, so EU-regulated operations should evaluate on Growth or Enterprise.
"It's based in EU so it fits our GDPR compliance requirements... The team is very reactive and helpful... They're improving the product continuously." - Robin L on G2
GDPR call recording audit checklist
- Require active opt-in (IVR key press or verbal confirmation) before recording begins, not passive notification
- Confirm your transcription vendor processes EU data within EU-west infrastructure and signs a Data Processing Agreement (DPA)
- Enforce automated retention policies that delete recordings and transcripts after 30 to 90 days and execute erasure requests via API within 30 days
- Verify your vendor does not train on customer audio (default on Growth and Enterprise plans, not Starter)
Auditing card data storage for PCI compliance
Defining PCI DSS scope for recordings
The PCI Security Standards Council prohibits storing sensitive authentication data (SAD) after authorization, including CVV values and PINs. The full primary account number (PAN) can be stored with proper encryption, but any call recording that captures a customer reading out a CVV or full card details violates PCI DSS storage rules unless you redact those elements before you retain the recording.
The scope question extends beyond the recording file. Any system, agent desktop, or network segment that touches cardholder data during the call falls within PCI DSS audit scope, and that is where pause-and-resume solutions consistently fall short.
PII redaction for payment cards
Automated PII redaction at the transcription layer detects and replaces payment data in the transcript before the output reaches downstream systems. PII redaction in our API must be explicitly enabled before any transcript is written to storage (it is not active by default) and replaces detected sensitive entities with structured tags such as [PII], [CREDIT_CARD_NUMBER], or [NAME].
Our PII redaction documentation details the full set of detectable entity types and the configuration parameters required to enable redaction in an async transcription workflow.
Pause-and-resume vs. automated redaction
The most common misconception in contact center PCI compliance is that pause-and-resume satisfies audit requirements. It does not. Sycurio's PCI DSS scope analysis shows that pause-and-resume addresses one element (call recordings) while agents, networks, systems, and telephony infrastructure remain in scope because they still handle cardholder data during the call. A single missed pause across a thousand calls is sufficient to bring your entire recording history into scope.
Companies relying on pause-and-resume must complete Self-Assessment Questionnaire D (SAQ-D), which involves significantly more security controls than environments that have fully removed cardholder data from the call recording and transcription layer. Automated redaction at the transcription layer, combined with Dual-Tone Multi-Frequency (DTMF) masking during the call itself, can reduce PCI obligations when properly supported by encryption in storage, access controls, audit logging, and retention management.
PCI DSS audit: 6-point checklist
- Enable DTMF masking during payment capture to prevent card digits from entering the audio stream
- Enable PII redaction for payment-related entity types before processing any recording
- Restrict recording storage access via Role-Based Access Control (RBAC) to compliance and QA roles only, with every access event logged and timestamped
- Consider replacing pause-and-resume with automated redaction that may reduce the scope of systems subject to PCI DSS audit
- Conduct regular scope reviews to verify no cardholder data persists in transcripts, recordings, or backups
- Document your redaction configuration as evidence for your SAQ submission to demonstrate that automated controls are consistently applied
Managing PHI and HIPAA in call recordings
What qualifies as PHI in call recordings
HIPAA does not prohibit recording patient calls. As WhatConverts notes:
"HIPAA doesn't prohibit recording patient calls. What it prohibits is unprotected PHI."
A recorded call that contains a patient's name, diagnosis, medication, appointment detail, or insurance information is Protected Health Information (PHI) under HHS guidance and falls under HIPAA's Privacy and Security Rules from the moment it is captured. For contact centers serving healthcare providers, health insurance plans, or any covered entity, you can record, but you must protect.
Vendor BAA checklist for HIPAA
If your vendor processes, stores, or transmits call recordings containing PHI, HHS classifies them as a Business Associate, and you must get a signed Business Associate Agreement (BAA) before you share any PHI. The BAA must cover the following:
- Define exactly how the vendor may use PHI (transcription processing only, not model training or fine-tuning)
- Prohibit re-disclosure of PHI beyond contract-permitted uses
- Require documented technical, physical, and administrative safeguards for PHI
- Include breach reporting obligations: vendor must report unauthorized PHI disclosure without unreasonable delay
- Extend BAA requirements to all subcontractors handling PHI on the vendor's behalf
- Specify data return or destruction procedures when the contract terminates
Our compliance hub documents HIPAA certification alongside SOC 2 Type II and ISO 27001 coverage.
Reducing PHI exposure in recordings
You need three controls for HIPAA compliance in recorded interactions:
- Encryption in transit and at rest: All audio and transcript data must be encrypted (TLS 1.2+ in transit, AES-256 at rest)
- Automated redaction: PII redaction, explicitly configured, replaces PHI entities in transcripts before outputs are written to downstream systems like Customer Relationship Management (CRM) or QA platforms
- Audit logging: Every access, modification, or deletion event on a recording or transcript containing PHI must generate a timestamped log entry accessible for HHS enforcement review. For multi-speaker healthcare calls, speaker diarization in our async workflows (powered by pyannoteAI's Precision-2 model) helps attribute patient and clinician speech accurately for compliance review. Diarization is available in async workflows only and delivers average 3x lower diarization error rate compared to alternatives.
Essential HIPAA checklist for CX teams
- Confirm a signed BAA is in place with every vendor handling PHI (transcription, storage, CRM) before any healthcare call data is shared
- Enable PII redaction for
medical_process, medical_condition, date_of_birth, and person entity types - Encrypt all PHI at rest (AES-256) and in transit (TLS 1.2+), and enforce RBAC so only authorized personnel can access PHI-containing records
- Maintain a complete audit log of every access and modification event on PHI records
How transcription tools simplify data audits
Automating PII redaction for compliance
The most common objection to automated redaction is that it degrades transcript accuracy or adds latency that breaks downstream LLM pipelines. The operational reality is different. Structured redaction replaces sensitive entities with consistent tags like [NAME] or [MEDICAL_ID], which allows downstream language models to maintain sentence-level context while the sensitive value is protected. The transcript remains usable for QA scoring, coaching, and CRM population.
Higher transcription accuracy directly improves compliance outcomes: more words captured correctly means more PHI entities detected and more reliable CRM data quality. Our async benchmark methodology documents how Solaria-1 performs on conversational speech across 7 datasets and 74+ hours of audio if you want to evaluate accuracy before a vendor decision. Because Solaria-1 recognizes speech accurately across 100+ supported languages, including 42 not available on any other API, named entities are still detected reliably in accented and code-switching BPO call queues, which is what redaction coverage actually depends on.
For European contact-center and business audio specifically, Solaria-3 ranks #1 against AssemblyAI, ElevenLabs, Deepgram, Mistral, and Speechmatics on real customer recordings across EN, FR, DE, ES, and IT, the language mix most common in EU and BPO call queues.
The operational cost impact of automated redaction at scale is predictable because our per-hour pricing includes all audio intelligence features in the base rate, with no add-ons for diarization, sentiment, or entity recognition.
Table 3: Compliance cost projections by monthly recording volume
| Monthly recording volume |
Starter plan ($0.61/hr async) |
Growth plan (from $0.20/hr async†) |
Features included |
| 100 hours/month |
$61 |
$20 |
Diarization, PII redaction, Named Entity Recognition (NER), sentiment, translation |
| 1,000 hours/month |
$610 |
$200 |
Diarization, PII redaction, Named Entity Recognition (NER), sentiment, translation |
| 10,000 hours/month |
$6,100 |
$2,000 |
Diarization, PII redaction, Named Entity Recognition (NER), sentiment, translation |
† $0.20/hr is the floor rate on the Growth plan, reached with an upfront volume commitment. Actual per-hour rate varies by commitment level. See current pricing for details.
Competitor pricing structures unbundle diarization, sentiment analysis, and entity recognition as separate add-ons. At 10,000 hours per month, AssemblyAI's fully-featured pre-recorded rate (Universal base at $0.15/hr, plus speaker diarization at $0.02/hr, entity detection at $0.08/hr, and sentiment at $0.02/hr) runs approximately $0.27/hour, and Deepgram's pre-recorded base rate alone, before any add-ons, is approximately $0.26/hour. Both sit above our Growth plan floor of $0.20/hour with every feature included in the base rate. We have publicly committed to remaining a pure-play audio infrastructure provider. Note the data training distinction: starter plan audio can be used for model training by default. Growth and Enterprise plan audio is never used for model training, with no opt-out action required.
Automated PII removal during recording
Our PII redaction is configured at the API request level. The following minimal async request uses parameters documented in the PII redaction API reference, with redaction enabled for credit card, phone, email, person, and medical entity types:
{
"audio_url": "https://your-storage.example.com/call-recording.wav",
"diarization": true,
"named_entity_recognition": true,
"redact_pii": true,
"redact_pii_audio": false,
"redact_pii_policies": [
"credit_card_number",
"phone_number",
"email_address",
"person",
"medical_process",
"date_of_birth"
]
}
The resulting transcript replaces matched entities:
{
"transcription": {
"full_transcript": "The patient [NAME] confirmed their date of birth as [DATE_OF_BIRTH] and provided card number [CREDIT_CARD_NUMBER]."
}
}
Documenting consent for regulatory review
Transcripts solve a QA coverage problem that manual sampling cannot. You can search 100% of transcripts to verify that agents delivered required consent disclosures on every call. With manual QA sampling covering only a small fraction of interactions, the majority of calls have no compliance verification. Full-text search across automated transcripts closes that gap without adding QA headcount.
Building a compliant call recording workflow
Obtaining valid consent for recording
IVR consent flows are the most reliable mechanism for obtaining active consent before a call is recorded. A compliant flow delivers the disclosure, requests an explicit input (key press or spoken confirmation), captures the consent event with a timestamp, and associates that event with the call identifier before recording begins.
Best practices for compliant archiving
- Encrypt recording files at rest using AES-256 and manage encryption keys separately from the data they protect
- Enforce retention limits that automatically expire recordings and transcripts after the regulatory minimum period
- Tag every recording at ingest with the applicable framework (GDPR, HIPAA, PCI), the consent event identifier, and the retention expiry date
- Store transcripts separately from audio files so that erasure requests can target both independently
Fulfilling GDPR erasure requests
A defensible right-to-be-forgotten workflow requires these steps:
- Receive and verify the request against the data subject's identity
- Locate all recordings and transcripts associated with that subject across primary storage, backup, and any downstream exports
- Execute deletion using the transcript delete API for transcript data and your storage platform's deletion API for audio files
- Purge backups containing the subject's data within the 30-day response window
- Log the deletion events with timestamps and the request identifier, then confirm deletion to the data subject in writing
Manual compliance processes create a predictable failure pattern. At low call volumes, agents can deliver consent prompts and pause recordings without significantly affecting AHT. At scale (1,000+ calls per day), manual consistency breaks down and every missed pause or forgotten disclosure becomes a compliance exposure that manual QA sampling cannot catch. Infrastructure-level controls at the transcription layer are the only mechanism that covers 100% of interactions without compounding operational cost.
Get started with us to test automated PII redaction on your own conversational audio and have your integration in production in less than a day.
FAQs
Does HIPAA prohibit recording patient calls?
No. HIPAA recording guidance permits recording patient calls, but any recording containing PHI must be secured with encryption, role-based access controls, and automated redaction before it is stored or transmitted to downstream systems. The prohibition is on unprotected PHI, not on recording itself.
Is manual pause-and-resume sufficient for PCI DSS compliance?
No. Pause-and-resume PCI scope analysis shows it removes only call recordings from PCI DSS scope, but agents, desktops, and telephony infrastructure remain in scope because they still handle cardholder data during the call, requiring companies to complete the more extensive SAQ-D audit process. Automated DTMF masking combined with PII redaction at the transcription layer is a more complete approach.
How long can contact centers retain call recordings under GDPR?
Under the GDPR right to erasure, recordings can only be retained for as long as necessary for the specified purpose, typically 30 to 90 days for standard customer service calls, though financial services obligations may extend this period. Automated expiry policies tied to the retention period and recording purpose are required to demonstrate compliance.
Does my transcription vendor need a BAA for HIPAA compliance?
Yes. Any vendor processing or storing recordings that contain PHI is a Business Associate under HHS regulations and must sign a BAA before receiving any PHI. The BAA must cover permitted uses, breach reporting obligations, subcontractor coverage, and data destruction at contract termination.
What entity types can automated PII redaction detect in healthcare and financial services calls?
PII redaction APIs PII redaction is a configurable capability within our transcription API. It detects and replaces entity types such as credit card numbers, bank account numbers, medical conditions, diagnoses, dates of birth, social security numbers, and patient names. Which entity types get redacted is up to your compliance requirements.
Key terms glossary
Average Handle Time (AHT): The average duration of a customer service interaction, measured from the moment the agent picks up the call until the customer hangs up, including hold time and after-call work. Critical for calculating operational cost per contact.
Interactive Voice Response (IVR): An automated telephony system that interacts with callers through voice prompts and keypad inputs. Used in compliance workflows to capture consent before an agent joins the call.
Customer Relationship Management (CRM): Software platforms that store customer interaction history, contact information, and business data. Transcripts are often exported to CRM systems for sales, support, and compliance tracking.
Role-Based Access Control (RBAC): A security model that restricts system access based on a user's role within an organization. Required under HIPAA and PCI DSS to limit who can view, modify, or delete recordings containing sensitive data.
Dual-Tone Multi-Frequency (DTMF): The signal system used when a caller presses keys on a telephone keypad. DTMF masking prevents card numbers entered via keypad from being recorded in the audio stream.
Named Entity Recognition (NER): A machine learning capability that identifies and classifies entities such as names, phone numbers, credit card numbers, and medical conditions in transcripts. Required for automated PII redaction workflows.
Business Process Outsourcing (BPO): The practice of contracting specific business operations, such as customer support or sales, to third-party service providers. BPO call centers often handle multilingual and accented speech at scale.
Word Error Rate (WER): The standard metric for speech-to-text accuracy, calculated as the percentage of deleted, inserted, or substituted words in a transcript relative to the reference text. Lower WER produces more reliable entity detection for compliance workflows.
Diarization Error Rate (DER): The metric used to evaluate speaker diarization performance, measuring the percentage of call time incorrectly attributed to the wrong speaker. Relevant for multi-party healthcare calls where patient and clinician speech must be attributed accurately.
Protected Health Information (PHI): Any individually identifiable health information covered under HIPAA, including names, diagnoses, medications, appointment details, and insurance data captured in a call recording or transcript.
Business Associate Agreement (BAA): A contract required under HIPAA between a covered entity and any vendor that handles PHI, specifying permitted uses, safeguards, breach reporting obligations, and data destruction requirements at contract termination.
Data residency: The physical or geographic location where an organization's data is stored and processed. GDPR restricts transfer of personal data outside the EEA unless adequacy decisions or appropriate safeguards are in place.
Pause-and-resume: A PCI DSS compliance method in which agents manually pause call recording during payment data capture. This removes only the recording from PCI audit scope but leaves agents, desktops, and telephony infrastructure in scope, requiring a more extensive audit process.
PII redaction: The automated process of detecting and replacing personally identifiable information in a transcript with structured tags (such as [NAME] or [CREDIT_CARD_NUMBER]) before the transcript is stored or exported to downstream systems.
