Compliance Resource
Incident Response for Call Data
A data incident is a bad time to work out who decides what. This guide covers what counts as an incident involving call data, the sequence to follow, and the preparation that makes the difference.
What counts as an incident
Unauthorised access to, or loss of, personal data. For call data that usually means recordings or enquiry records reaching someone who should not have them, an integration exposing records more widely than intended, a misdirected export, or an account compromise.
The Personal Data Protection Act includes a data breach notification obligation. In general terms, an organisation must assess a suspected breach, and where the breach is notifiable, inform the Personal Data Protection Commission and, in certain cases, affected individuals. Thresholds, timeframes and the details of what must be reported are set out in the legislation and the Commission’s guidance.
The specific requirements that apply to your business, and the deadlines involved, should be confirmed with your own advisers and against the current published guidance. Do not rely on a supplier’s summary, including this one, when a live incident is running.
The response sequence
Containment first, assessment second, notification third, correction last. Skipping to notification without assessment usually produces an inaccurate report.
1. Contain
Stop the exposure continuing: revoke access, disable the integration, recall or restrict the export, reset the affected credentials. Record the time of each action.
2. Assess
Establish what data was involved, how many individuals, how it was exposed, and whether it has been accessed. Your data protection officer leads this, not the person who found it.
3. Decide on notification
Determine, with your advisers, whether the breach is notifiable, and to whom. Where notification is required, timeliness matters, so start this assessment immediately rather than after the investigation concludes.
4. Notify
Report to the Commission where required, and to affected individuals where the criteria are met. Keep the record of what was sent, to whom and when.
5. Correct
Fix the underlying cause, not just the instance. Update access lists, integration settings, retention or training, and record what changed.
Suppliers processing data on your behalf are generally expected to inform you of a breach affecting your data without undue delay, so that you can meet your own obligations. Confirm that this is written into your agreement, as covered in vendor due diligence.
How call data incidents usually start
Misdirected export
A spreadsheet of enquiries sent to the wrong recipient. Common, entirely preventable, and a reason to restrict who can export at all.
Departed staff access
An account that was never disabled. Offboarding that covers call systems and shared inboxes closes this route entirely.
Integration misconfiguration
Records written to the wrong destination, or a connection granting broader permissions than intended. Verify writes during testing, not after launch.
Compromised credentials
A reused password or a phishing message. Individual accounts and multi-factor authentication reduce both the likelihood and the blast radius.
Messaging leakage
Call summaries forwarded into a group chat that includes people outside the business. Decide what alerts may contain before this happens.
Supplier incident
An incident at a provider in your chain. You need their notification commitment in writing and a current list of who is in that chain.
Prepare before you need it
Most of the work is done in advance. An hour spent on this now removes the worst of the confusion later.
- A named incident lead and a deputy, both reachable outside office hours
- A current map of where call data is held, including suppliers and middleware
- Contact details for every provider in the chain, kept outside the affected systems
- Knowledge of what logging exists in each system, checked before an incident
- An agreed route to legal and data protection advice at short notice
- A simple incident log template, ready to use
- Draft holding wording for staff answering calls about an incident
- The ability to disable an integration or account quickly, held by more than one person
- A short annual walkthrough of a plausible scenario with the people involved
Keep an incident log from the first minute. Record what was found, when, by whom, and every decision taken since. Reconstructing a timeline afterwards from memory is unreliable, and the log is usually the most useful document you will have.
Retaining less data also makes incidents smaller. Where a recording no longer serves a purpose, its deletion removes it from every future incident, as covered in data retention for call records.
Frequently asked questions
Does every incident have to be reported?
No. Notification obligations apply where the breach meets the criteria set out in the legislation, which is why assessment comes before reporting. Your advisers should make that call against the current guidance.
How quickly must we act?
Assessment is expected to be prompt, and notification deadlines apply once a breach is found to be notifiable. Check the current timeframes with the Personal Data Protection Commission rather than working from a remembered figure.
Who should lead the response?
Your data protection officer, with authority to instruct containment. The person who discovered the incident should report it, not investigate it alone.
What if the incident is at a supplier?
You still have your own obligations. That is why supplier notification commitments and a current sub-processor list matter before anything goes wrong.
Should we tell affected callers?
Where the criteria for notifying individuals are met, yes, and even where they are not, there may be good reasons to. Take advice, and prepare wording that is honest about what happened.
How do we stop it happening again?
Fix the cause rather than the instance: access lists, integration settings, retention, alerting and training. Then retest, including the checks in testing before go-live.
Related reading
The full compliance series is in the resources library.
Know your data path before you need it
We will document exactly where a call record travels in your setup, so an incident map exists before there is an incident to map.