Caught Up in a CRM Data Breach? Start Here
A practical guide to assessing the risk, securing connected systems, notifying the ICO and communicating with the people affected.
The recent security incident involving Beacon CRM has understandably caused concern among organisations using the platform.
However, Beacon is not the first CRM provider to experience a security incident, and it will not be the last.
Organisations increasingly rely on external platforms to manage customer information, donations, memberships, service users, event bookings, sales activity, case records and communications. When one of those suppliers experiences a breach, the consequences can quickly reach far beyond its own systems.
The same principles also apply when the incident happens inside your organisation. A data breach could involve a hacked account, a stolen laptop, an email sent to the wrong person, an exposed spreadsheet, a compromised website form or an employee accessing information without permission.
Whatever has happened, the immediate priorities are the same.
Contain the incident. Establish what information may be affected. Assess the risk to people. Record your decisions. Communicate clearly. Meet any legal or contractual obligations.
This guide explains what to do next.
It is intended as practical guidance rather than legal advice. Where necessary, speak to your Data Protection Officer, legal adviser, cyber security provider or the Information Commissioner’s Office.
Not every data breach looks like a cyberattack
The term “data breach” often brings to mind hackers breaking into a system. That is only one possibility.
A personal data breach can involve the accidental or unlawful destruction, loss, alteration, disclosure of or access to personal information. It can therefore include situations such as:
A CRM account being accessed by an unauthorised person.
Information being downloaded from a supplier’s system.
A member of staff emailing personal information to the wrong recipient.
A laptop, telephone or storage device being lost or stolen.
A spreadsheet being shared publicly by mistake.
Login details or API keys being exposed.
An employee viewing records they were not authorised to access.
Information being deleted without a usable backup.
A website form sending submissions to the wrong place.
Malware or ransomware preventing access to records.
The first task is therefore to establish what has actually happened rather than relying on the language used in an initial supplier notification.
Understand who is responsible
Where your CRM is provided by an external company, the supplier will usually act as a data processor. Your organisation will usually remain the data controller. The processor operates the system and handles information on your behalf. The controller decides why the information is collected, what it is used for and how it should be managed.
The supplier must tell you about a personal data breach without undue delay and assist with your response. However, your organisation remains responsible for deciding whether the incident must be reported to the ICO and whether affected individuals need to be contacted.
That can feel unfair when the problem originated with someone else’s system, but using an external provider does not transfer your organisation’s responsibilities for the information. The decisions you make must be based on the information held in your particular CRM, not simply on the supplier’s overall description of the incident.
Establish what is known
Start by gathering the facts available at that point. You may not receive a complete explanation immediately. Cyber incidents can take days or weeks to investigate properly. Your initial assessment may therefore need to change as more information becomes available.
Try to establish:
When the incident happened.
When your organisation became aware of it.
Which systems or accounts were involved.
Whether information was accessed, changed, downloaded, deleted or encrypted.
Whether the incident is ongoing.
Which records may be affected.
Whether passwords, API keys or other credentials may have been exposed.
Whether there is any evidence that the information has been misused.
What the supplier or your technical team has done to contain the incident.
When further information is expected.
Separate confirmed facts from assumptions. It is reasonable to make decisions using incomplete information, but your incident record should make clear what was known at each stage.
Appoint one person to lead the response
Choose one person to coordinate the organisation’s response. They do not need to undertake every task personally. Their role is to maintain a clear overview, coordinate the people involved and ensure that important actions are not missed.
Depending on the scale of the incident, the response team may include:
Senior management.
Your Data Protection Officer or data protection lead.
IT staff or an external technology provider.
Legal advisers.
Communications staff.
Human resources.
Safeguarding leads.
Customer or service-user support staff.
Members of the board or governing body.
The lead person should maintain a central incident log containing actions, decisions, dates, communications and outstanding questions.
This also gives the supplier one clear point of contact. Several people sending overlapping questions can slow the response and create confusion.
Contain the incident
Your immediate technical actions will depend on what happened. Possible steps include:
Resetting affected passwords.
Signing users out of all active sessions.
Suspending compromised accounts.
Enforcing multi-factor authentication.
Revoking exposed API keys.
Disconnecting compromised integrations.
Restricting access to affected systems.
Isolating infected devices.
Removing publicly accessible files.
Blocking suspicious email rules or forwarding settings.
Contacting your hosting, IT or cyber security provider.
Preserving logs and other evidence.
Do not make major changes blindly. Some actions may destroy information needed to investigate what happened.
Where possible, coordinate containment with the supplier, your IT provider or a cyber security specialist. However, do not leave obviously compromised accounts or credentials active while waiting for a perfect plan.
Revoke API keys and check every integration
API keys allow your CRM to exchange information with other systems.
If a CRM or connected account has been compromised, those credentials may provide a route into other parts of your digital infrastructure. They may also allow someone to continue accessing or transferring information after the original incident has been contained.
Your CRM may be connected to:
Website forms.
Payment and donation platforms.
Email marketing systems.
Zapier, Make or similar automation tools.
Accounting software.
Event registration systems.
Membership platforms.
Reporting dashboards.
Cloud storage.
Customer-support tools.
Custom applications.
Other internal databases.
Identify every integration. Revoke the existing API keys where the incident creates a reasonable possibility that they have been exposed. Generate new credentials and reconnect each system securely. Switching off an automation is not necessarily the same as revoking the credential it uses. The old key must be made invalid.
Once systems have been reconnected, test them properly. Check that:
Forms are creating records correctly.
Payments are still being recorded.
Automated messages are being triggered correctly.
Information is flowing in the right direction.
Records are not being duplicated.
Required information is not being lost.
Old or unused connections have been removed.
This is also a good opportunity to identify integrations that nobody remembers creating or that are no longer required.
Find your existing policies
Your organisation may already have policies covering:
Personal data breaches.
Cyber security incidents.
Business continuity.
Disaster recovery.
Crisis communications.
Safeguarding.
Records management.
Complaints.
Notification of the board or governing body.
Find them and follow them.
Check who must be informed, who has authority to make decisions and what records must be retained.
A policy that exists only in a folder is not much use during a real incident. If your policies are incomplete, unclear or out of date, document how the response is being managed and make a note to revise them afterwards.
Work out what information was involved
The seriousness of the incident depends heavily on the information that may have been compromised.
A CRM containing names and workplace email addresses presents a different level of risk from one containing case notes, health information, financial details or safeguarding records.
Review what your organisation actually held, including:
Names.
Home addresses.
Email addresses.
Telephone numbers.
Dates of birth.
Account passwords.
Payment or donation histories.
Bank or financial information.
Employment records.
Health information.
Disability and accessibility information.
Information about children and young people.
Safeguarding information.
Case notes.
Criminal allegations or convictions.
Religious or political beliefs.
Immigration or residency information.
Details of vulnerable people.
Confidential correspondence.
Do not consider fields only in isolation.
Several apparently ordinary pieces of information can become much more sensitive when combined. A person’s name, address, date of birth and relationship with a particular service could expose them to fraud, embarrassment, discrimination or personal danger.
Also consider:
How many people may be affected.
Whether the information was encrypted.
How easily individuals could be identified.
Whether the records relate to vulnerable people.
Whether the information could be used for fraud or impersonation.
Whether disclosure could cause distress, reputational harm or discrimination.
Whether anyone could be put at physical risk.
Whether the information is already publicly available.
Whether there is evidence of deliberate targeting or misuse.
The assessment must focus on the possible consequences for people, not only the inconvenience caused to the organisation.
Decide whether the ICO must be notified
Not every personal data breach must be reported to the ICO.
You must assess whether the incident is likely to result in a risk to people’s rights and freedoms. Where a risk is likely, the ICO must be notified as soon as possible and, where feasible, within 72 hours of your organisation becoming aware of the breach.
The 72-hour period does not begin when the supplier finishes its investigation. It begins when your organisation has enough information to be aware that a personal data breach has occurred.
You may not have every detail within that period. The ICO allows organisations to make an initial report and provide further information as the investigation develops.
Your decision should consider:
The type of information involved.
The sensitivity of that information.
The likely consequences for individuals.
The number of people affected.
Whether children or vulnerable people are involved.
Whether the information was protected.
Whether it appears to have been accessed or downloaded.
Whether there is evidence of misuse.
What has been done to reduce the risk.
The ICO provides an online self-assessment tool to help organisations decide whether a breach needs to be reported. If you decide that notification is not required, record the decision and explain why.
You should document all personal data breaches, including those that are not reported. Your record should show that the organisation considered the risks and reached a reasoned decision. Where you remain uncertain, contact the ICO or obtain appropriate professional advice.
Check your other reporting obligations
The ICO may not be the only organisation that needs to know. Depending on your sector, contracts and insurance arrangements, you may also need to contact:
A sector regulator.
Your cyber insurance provider.
A professional or accreditation body.
A government department.
A local authority.
A commissioning organisation.
A funding body.
A client whose information you process.
A partner organisation.
The National Cyber Security Centre.
Law enforcement.
Check your contracts, data-processing agreements, funding conditions and insurance documents.
Some agreements require notification within a set period even where the incident does not reach the threshold for reporting to the ICO.
For charities
Charities should also consider the requirements of the relevant charity regulator and the responsibilities of trustees. The correct action will depend on where the charity is registered, the seriousness of the incident and the potential consequences for the organisation and its beneficiaries.
For public and regulated organisations
Public bodies and organisations operating in regulated sectors may have additional reporting duties. Health, social care, education, financial services and organisations delivering public contracts may need to involve regulators, commissioners or other statutory bodies.
Do not assume that reporting the incident to the ICO automatically meets every other obligation.
Decide whether individuals need to be told
The threshold for notifying individuals is higher than the threshold for reporting to the ICO.
People must be informed without undue delay where the breach is likely to result in a high risk to their rights and freedoms.
An organisation may therefore need to notify the ICO without needing to contact every person in its CRM.
Do not immediately send a message to your entire database because it feels like the safest option.
An unnecessary mass communication can create alarm, damage confidence and generate a significant number of enquiries. It may also provide useful material for scammers attempting to impersonate your organisation.
Equally, do not avoid necessary communication because it may be uncomfortable or embarrassing.
Where people need to be notified, explain:
What happened.
When it happened.
What categories of information were involved.
What the realistic risks are.
What your organisation has done.
What the supplier has done, where relevant.
What individuals should do to protect themselves.
How they can contact you.
How they can verify that the communication is genuine.
Use clear and direct language.
Do not minimise the situation. Do not speculate. Do not bury the important information beneath legal or technical terminology.
Keep breach communications separate from marketing.
A data-breach notification is an operational communication, not a marketing campaign.
If you need to use an email platform to contact affected people, create a separate audience or securely isolated list. Do not add people to your general marketing database or change their marketing preferences. The information should be used only for the incident communication and then handled in accordance with your retention policies.
Consider disabling unnecessary email tracking and promotional content. The message should not contain sales messages, marketing calls to action or unrelated organisational news. Make it easy for recipients to confirm that the message is genuine without clicking suspicious links or providing further personal information.
Tell the right people inside the organisation
Senior management and the board or governing body should be informed early. Staff, contractors and volunteers may also need an internal briefing, particularly if they deal directly with customers, members, donors, service users or the public.
They should know:
What has been confirmed.
What remains under investigation.
What action the organisation has taken.
What they should say if someone contacts them.
What they should not speculate about.
Where questions should be directed.
How suspicious messages or activity should be reported.
Everyone should work from the same agreed facts. Conflicting messages can quickly undermine confidence and make the incident more difficult to manage.
The NCSC recommends that cyber incident communications are coordinated, accurate and timely, with clear responsibility for what is communicated and to whom.
Be ready for phishing and impersonation
A publicised breach can create opportunities for criminals even where the original information has not been misused.
Staff and affected individuals may receive:
Fake password-reset messages.
Fraudulent payment requests.
Calls pretending to come from your organisation.
Emails impersonating the CRM provider.
Messages asking people to confirm personal details.
Links to fake login pages.
Threats claiming that information will be published.
Warn staff to treat unexpected messages with caution. Where you contact affected people, make clear:
Which email address you will use.
Whether you will contact them by telephone.
What information you will never ask them to provide.
How they can independently verify a message.
Where suspected scams should be reported.
Keep a detailed incident record
Record every significant action and decision. Your incident log should include:
When the incident occurred, where known.
When your organisation became aware of it.
Who was informed.
What systems were affected.
What information may have been involved.
What immediate containment action was taken.
Which passwords and API keys were changed.
Which integrations were disconnected and restored.
How the risk to individuals was assessed.
Whether the ICO was contacted.
Whether another regulator or contractual partner was contacted.
Whether individuals were notified.
Copies of communications.
Advice received from specialists.
Outstanding questions.
The reasoning behind decisions not to report or notify.
A good record protects the organisation and helps demonstrate that the incident was handled responsibly.
It will also make the eventual review much more useful.
When the immediate incident is over
Once the immediate risk has been controlled, carry out a proper review. The main lesson from a supplier breach is straightforward. Outsourcing a system does not outsource responsibility for the information inside it.
Review every third party that stores or processes personal information on your behalf. This may include:
CRM platforms.
Email marketing systems.
Website hosts.
Cloud storage.
Payment providers.
Accounting platforms.
Survey tools.
Event systems.
Forms.
Automation platforms.
Customer-support systems.
Human resources software.
File-transfer services.
For each supplier, establish:
What information it holds.
Why it holds that information.
How long it retains the information.
Which other systems it connects to.
Who can access it.
Whether multi-factor authentication is enforced.
What its contract says about security.
How quickly it must notify you of a breach.
What happens to your information if you leave the platform.
Whether old or unnecessary information can be deleted.
You should also:
Remove dormant user accounts.
Review permissions and administrator access.
Remove unused integrations.
Rotate API keys and other credentials.
Enforce multi-factor authentication.
Reduce the amount of personal information retained.
Review your backups.
Update your data-protection documentation.
Review your cyber insurance.
Train staff to recognise threats.
Update your incident-response plan.
Test the plan before another incident happens.
The NCSC recommends that organisations maintain and regularly review an incident-response plan so that roles, escalation routes and key actions are understood before a crisis occurs.
Do not wait for perfect information
Your organisation may not know exactly what happened when it first becomes aware of an incident. That does not prevent you from taking sensible action.
Secure the affected accounts. Revoke potentially compromised credentials. Check your integrations. Identify the information involved. Begin the risk assessment. Inform the right people. Start an incident log.
Then keep reviewing the situation as new facts emerge. The organisations that handle data breaches well are not necessarily those that have every answer immediately. They are the organisations that act promptly, make careful decisions, maintain accurate records and communicate honestly.
TMD helps organisations improve their CRM systems, integrations, digital infrastructure and communications. We are not legal or cyber security advisers, but we can help you understand how your systems connect, identify operational weaknesses and communicate clearly with the people affected. Get in touch if your organisation needs practical support.
