International Call Recording Compliance

Most call recording mistakes happen before anyone opens the legal handbook. The PBX starts writing audio, the files land in a shared folder, and only later does someone ask what the caller was told, why the call was recorded, how long the file should live, or whether the caller had a real choice.

This page is meant to prevent that problem. It is a practical compliance reference for Asterisk systems that use MixMonitor(), AMI recording actions, or any external recorder attached to SIP/RTP media.

It is also the international companion to Call Recording Consent Laws by State.

Last reviewed: August 1, 2026

The safe engineering default

If your callers may be outside the United States, do not build the dialplan around one global consent rule. Build it around a documented recording purpose and a conservative routing decision.

A good default looks like this:

• Announce the recording before recording starts.
• Say why the call is being recorded.
• Give the caller a reasonable unrecorded path when consent is required or when your policy promises one.
• Store enough metadata to prove what the caller was told, when they were told, and how consent was captured.
• Keep recordings only as long as the documented purpose requires.
• Encrypt recordings at rest and limit who can play, export, or delete them.
• Treat health, biometric, financial, employment, and child-related calls as higher-risk from the beginning.
• When caller location is uncertain, apply the stricter plausible rule.

The notice matters. "This call may be recorded" is usually too thin by itself. A better notice says something like, "This call may be recorded for support quality and dispute resolution." That gives the caller a real explanation, and it gives the business a purpose that can drive retention and access control.

Quick jurisdiction map

European Union: GDPR

In the EU, a call recording is usually personal data. The GDPR, Regulation (EU) 2016/679, controls the processing of the recording, but it does not answer every recording question, because member-state communications laws may still control whether the call may be recorded in the first place. The GDPR answers what happens once you collect, store, use, disclose, search, export, or delete the recording and its metadata.

That distinction is important for Asterisk administrators. A dialplan can satisfy a business workflow and still create a privacy problem if it records more than needed, keeps files too long, or cannot find a caller's recording when they make a request.

Under GDPR Article 6, the controller needs a lawful basis. Common candidates are:

• Consent, Article 6(1)(a): useful when the caller can freely refuse recording and still get a reasonable service path.
• Contract, Article 6(1)(b): possible when recording is genuinely necessary to provide or document the service the caller requested.
• Legal obligation, Article 6(1)(c): relevant where a law or regulator requires recording.
• Legitimate interests, Article 6(1)(f): possible for security, fraud prevention, dispute resolution, or quality control, but only after a balancing test and only when the caller would reasonably expect it.

Consent is not the easy button. It must be freely given, specific, informed, and unambiguous. If the caller cannot realistically refuse, consent may be the wrong lawful basis. In that case, document the actual basis and still tell the caller what is happening.

What the announcement should say

The short audio prompt should cover the immediate facts and point to fuller privacy information. For a GDPR-style notice, include:

• That the call is being recorded or may be recorded.
• The purpose, such as support quality, transaction evidence, security, fraud prevention, or regulatory compliance.
• The organization responsible for the recording.
• Whether continuing the call is treated as consent or whether the caller must press a key or say yes.
• Where the caller can find the full privacy notice, including retention, sharing, and rights.

Example:

Calls to ExampleCo support may be recorded for support quality and dispute resolution. The recording is kept for 90 days unless needed for an active case. To continue without recording, press 2 or visit example.com/privacy for other contact options.

Retention and sensitive content

The GDPR does not set one fixed call-recording retention period. The period should follow the purpose. A support-quality recording kept for 30 days, a dispute-resolution recording kept for 90 days, and a regulated financial recording kept for years are different records with different justifications.

Voice recordings are not automatically biometric special-category data. They become biometric data under GDPR Article 9 when they are processed with technical means for unique identification. A normal support recording can still contain special-category data if the caller discusses health, religion, union membership, or other sensitive subjects. If that is likely in your environment, treat the recording path as higher-risk.

Data subject rights

A caller may have rights to access, erasure, restriction, objection, and portability depending on the lawful basis and facts. In PBX terms, the hard part is usually operational:

• Can you find the recording from a phone number, account, ticket, or date range?
• Can you identify all linked call legs after transfers?
• Can you separate the requester's voice from other participants if required?
• Can you delete the live file, archive copy, and backup copy when deletion is required?
• Can you prove what happened?

That is why the metadata design matters as much as the dialplan.

United Kingdom

The UK uses UK GDPR plus the Data Protection Act 2018. ICO guidance on call monitoring is practical and direct: tell people that calls are being recorded and explain why. A recorded message is good practice. Where that is not possible, staff should tell callers directly.

PECR sits alongside UK GDPR and becomes especially important for marketing calls and electronic communications. If the call flow is sales, lead generation, debt collection, or campaign outreach, do not assume a generic quality-monitoring notice covers everything. Check PECR, suppression lists, opt-outs, and campaign consent separately.

For Asterisk, the UK-friendly implementation pattern is simple:

• Play the notice at the edge of the IVR, before recording starts.
• Use purpose-specific prompts instead of one vague prompt for every queue.
• Link the prompt to a public privacy notice.
• Keep the recording purpose and retention period in metadata.
• Avoid routine personal-call or staff-call recording unless the purpose is strong and documented.
• Make subject access request handling part of the recording workflow.

Canada: PIPEDA and provincial privacy laws

Canadian call recording is easy to oversimplify. Many administrators hear "one-party consent" and stop there. That is not enough for an organization recording customer calls.

For private-sector organizations under PIPEDA, the Office of the Privacy Commissioner of Canada says an organization should tell the customer the call is being recorded, clearly state the purpose, and ask for consent. If the customer continues after knowing that the call is recorded and why, consent may be implied. If the customer objects, the OPC expects an alternative, such as an unrecorded path, mail, online service, or an in-person option.

Use this mental model:

• Consent under Criminal Code section 184 asks whether the recording is an unlawful interception.
• Privacy-law consent asks whether the organization may collect, use, retain, disclose, and dispose of the caller's personal information.

Those are different questions.

Provincial law can add obligations. Quebec Law 25 is the major one to watch because it strengthens governance, transparency, retention, destruction, anonymization, privacy impact assessment, and cross-border communication duties. Alberta PIPA and British Columbia PIPA may also apply depending on the organization and transaction.

Australia

Australia needs extra care because federal and state rules overlap.

At the federal level, the Telecommunications (Interception and Access) Act 1979 regulates interception of communications passing over a telecommunications system. State and territory surveillance-device statutes then regulate listening devices and private conversations.

The state and territory rules are not uniform. That is the key point for PBX design. A few examples show the spread:

• Western Australia restricts recording private conversations by a party unless an exception applies, including consent of each principal party or a lawful-interest exception.
• Queensland has a participant exception where the person using the listening device is a party to the private conversation.
• Victoria focuses its core listening-device offence on recording a private conversation to which the recorder is not a party, but use, communication, publication, workplace privacy, and other rules can still matter.
• South Australia restricts recording a private conversation by a party unless all principal parties consent or another exception applies.
• New South Wales has its own consent and lawful-interest exceptions for private conversations.

For a national Australian call center, the safest technical pattern is to announce recording and obtain at least implied consent before starting MixMonitor(). If the caller objects, route to an unrecorded path or stop recording. Do not rely on a simplified state label unless counsel has reviewed the exact call flow.

The Privacy Act 1988 and Australian Privacy Principles also matter after the recording exists. APP 11 requires reasonable steps to protect personal information and to destroy or de-identify it when it is no longer needed, unless an Australian law or court order requires retention.

Cross-border calls and hosted storage

For VoIP systems, location is not just the PBX address. A single call can involve several relevant places:

• Caller physical location.
• Agent physical location.
• Organization location.
• SIP trunk provider location.
• PBX location.
• Recording storage location.
• Backup and analytics provider location.
• The country whose residents are being targeted by the service.

When those point to different jurisdictions, use the stricter-rule-wins convention unless counsel has approved another approach. In practice, that usually means clear notice, documented purpose, consent capture when possible, and an unrecorded alternative.

For EU and UK personal data, sending recordings to another country may trigger transfer rules. Standard Contractual Clauses, adequacy decisions, transfer impact assessments, and supplementary safeguards may be required depending on the destination and vendor.

A recording stored in a US object-storage bucket can be a cross-border transfer even if the PBX is in Europe and the caller never leaves Europe.

Asterisk implementation pattern

1. Decide before the call whether recording is allowed

Do not start MixMonitor() and then decide later whether the recording was allowed. Route through a recording policy step first.

Useful policy inputs include:

• DID or campaign.
• Queue or department.
• Caller account country.
• Caller ID country as a weak signal.
• Agent location.
• Language.
• Recording purpose.
• Whether the call is regulated, support, sales, emergency, employment, or healthcare.

If location is unknown, default to the stricter policy.

2. Play a purpose-specific announcement

Use different prompts for different purposes and languages. Do not reuse one vague prompt everywhere.

[recording-consent]
exten => s,1,NoOp(Recording consent gate for ${ARG1})
 same => n,Set(RECORDING_PURPOSE=${ARG1})
 same => n,Playback(custom/recording-notice-${CHANNEL(language)})
 same => n,Read(CONSENT_DIGIT,custom/press-1-to-consent,1,,1,8)
 same => n,GotoIf($["${CONSENT_DIGIT}"="1"]?accepted:declined)
 same => n(accepted),Set(RECORDING_CONSENT=yes)
 same => n,Set(RECORDING_CONSENT_AT=${STRFTIME(${EPOCH},,%Y-%m-%dT%H:%M:%S%z)})
 same => n,Set(RECORDING_BASIS=consent)
 same => n,Return()
 same => n(declined),Set(RECORDING_CONSENT=no)
 same => n,Return()

This example is intentionally explicit. If your reviewed policy allows implied consent, you can capture continued participation instead of a keypress. Still store the notice version and timestamp.

3. Start MixMonitor only after the policy step

[inbound-support]
exten => _X.,1,NoOp(Inbound support call)
 same => n,Gosub(recording-consent,s,1(support-quality))
 same => n,GotoIf($["${RECORDING_CONSENT}"!="yes"]?no_recording)
 same => n,Set(REC_DATE=${STRFTIME(${EPOCH},,%Y/%m/%d)})
 same => n,Set(REC_FILE=${REC_DATE}/${UNIQUEID}.wav)
 same => n,MixMonitor(${REC_FILE},b)
 same => n,Set(CDR(recording_file)=${REC_FILE})
 same => n(no_recording),Queue(support)

Create the date directories with the correct owner and permissions before calls arrive. Keep recordings outside the web root.

4. Store DSAR-ready metadata

A recording without useful metadata is a future support ticket waiting to happen. Store a small row for each recording in a database table or external system.

5. Encrypt recordings at rest

Asterisk does not encrypt MixMonitor() output by itself. Put controls around the storage:

• Put recordings on an encrypted filesystem or encrypted object-storage bucket.
• Use restrictive filesystem permissions for the Asterisk process and retrieval service.
• Separate PBX operators from recording reviewers.
• Log every playback, export, and deletion.
• Keep recordings out of normal web-accessible paths.
• Rotate keys and document the recovery process.

For higher-risk recordings, encrypt per tenant, per purpose, or per retention class so access control and deletion are easier to prove.

6. Prune by purpose, not by one global age

Different purposes need different retention periods. Avoid one global retention value unless every call really has the same purpose.

A simple daily pruning job can work if the metadata already separates recordings by purpose:

find /var/spool/asterisk/recording/support-quality -type f -mtime +90 -name '*.wav' -delete
find /var/spool/asterisk/recording/training -type f -mtime +30 -name '*.wav' -delete

For production, prefer a retention worker that deletes by database metadata, logs the deletion, and marks the row as deleted. Filesystem age alone does not prove the purpose or legal basis.

7. Make access requests boring

A DSAR or privacy access request should not turn into a manual hunt through recording folders. Build the lookup path now:

1. Search by caller number, account, date range, ticket, or email-linked account.
2. Match candidate calls by uniqueid and linkedid.
3. Review whether the recording contains third-party voices or sensitive information.
4. Export only what the requester is entitled to receive.
5. Redact or withhold where required by the applicable law.
6. Log the request, decision, export, and deletion if deletion is required.

A practical policy matrix

Use this as a starting point for the internal recording policy that your dialplan enforces.

Related Asterisk references

• MixMonitor() records and mixes call audio.
• StopMixMonitor() stops a recording and closes the file handle.
• MIXMONITOR() retrieves MixMonitor instance data.
• Selective Call Recording shows a practical recording toggle pattern.
• Call Recording Consent Laws by State covers US state consent rules.

Official sources used

• GDPR, Regulation (EU) 2016/679
• European Data Protection Board: legal basis
• European Data Protection Board: standard contractual clauses
• ICO: specific data protection considerations for monitoring workers
• ICO: Guide to PECR
• UK Data Protection Act 2018
• UK PECR statutory instrument
• Canada PIPEDA
• Canada Criminal Code, section 184
• Office of the Privacy Commissioner of Canada: Recording of Customer Telephone Calls
• Alberta Personal Information Protection Act
• British Columbia Personal Information Protection Act
• Quebec CAI: principal changes under Law 25
• Quebec CAI: retention and destruction of personal information
• Quebec Act respecting the protection of personal information in the private sector
• Australian Telecommunications (Interception and Access) Act 1979
• Australian Privacy Act 1988
• OAIC: APP 11 security of personal information
• Western Australia Surveillance Devices Act 1998
• Queensland Invasion of Privacy Act 1971, section 43
• Victoria Surveillance Devices Act 1999
• South Australia Surveillance Devices Act 2016
• NSW Surveillance Devices Act 2007