A message arrives from your CRM provider informing you that it has experienced a security incident.
It may explain that unauthorised access took place, that customer data could have been involved and that an investigation is under way.
At that point, many organisations make an understandable assumption:
The supplier experienced the breach, so the supplier will deal with it.
The supplier certainly has responsibilities.
It must investigate what happened, secure its systems, preserve evidence and communicate with affected customers.
However, that does not remove your organisation’s own responsibilities.
When the system contains your supporters’, clients’, employees’ or service users’ personal data, you need to assess what the incident means for them—and what your organisation must do next.
This is where a supplier incident quickly becomes more than a technical problem.
It becomes an issue involving data protection, governance, safeguarding, communications and reputation.
The Important Difference Between a Data Controller and a Data Processor
In many CRM relationships, the organisation using the platform is the data controller, while the CRM provider acts as the data processor.
The controller decides why personal data is collected, what information is stored and how it is used.
The processor handles that data on the controller’s behalf.
This distinction matters because the organisation using the CRM normally remains responsible for assessing the risk to the individuals whose information it holds.
The provider cannot make every decision for you.
It does not know the full context behind your database.
A name and email address used for a newsletter may present one level of risk.
The same CRM might also contain donor histories, financial information, case notes, safeguarding details, health information or records revealing someone’s vulnerability.
The impact depends on what your organisation stored—not simply what the platform was technically capable of holding.
Do Not Wait for Perfect Information Before Acting
In the early stages of an incident, the supplier may not yet have all the answers.
That does not mean your organisation should do nothing.
Begin by recording:
- When you first became aware of the incident
- What the supplier has confirmed
- Which systems and integrations may be affected
- What categories of personal data were stored
- Approximately how many people could be involved
- Which internal stakeholders have been informed
- What actions have already been taken
Keep assumptions separate from confirmed facts.
An incident log becomes extremely valuable when information changes, questions arise later or regulators ask how decisions were made.
Revoke Connected Integrations and Credentials
CRMs rarely operate in isolation.
They may be linked to:
- Website forms
- Email marketing platforms
- Payment systems
- Accounting software
- Automation tools
- Event platforms
- Reporting applications
- Fundraising systems
- Other databases
Where the supplier recommends it, revoke and replace connected API keys, access tokens and integration credentials.
This can prevent credentials potentially exposed during one incident from being used to access other systems.
Do not simply change an employee’s CRM password and assume the job is complete.
Map the systems connected to the platform and confirm that every relevant connection has been reviewed.
Appoint One Person to Lead the Response
Supplier incidents become harder to manage when several people contact the provider separately.
Questions become duplicated.
Information is stored in different inboxes.
People receive different answers at different times.
Appoint one incident lead to coordinate:
- Communication with the supplier
- Evidence and documentation
- Technical actions
- Internal updates
- Data protection decisions
- Regulatory communication
- Communications with affected individuals
This person does not need to handle every task personally.
Their role is to make sure those tasks are coordinated and that the organisation maintains one reliable version of events.
Depending on the organisation, the response team may include senior management, IT, data protection, communications, safeguarding and trustees or board members.
Find and Follow Your Own Policies
Most organisations already have documents that explain how they intend to respond to an incident.
These may include:
- A personal data breach procedure
- An incident response plan
- A data protection policy
- A business continuity plan
- A safeguarding policy
- A supplier management policy
- A communications plan
A real incident is not the time to discover that nobody knows where these documents are stored.
Locate them, review them and follow the actions they require.
Check who must be informed, who is authorised to make decisions and what evidence must be retained.
When the incident is over, update any process that proved unclear or impractical.
Assess the Actual Risk to People
A data breach should not be judged only by the size of the database.
The important question is what harm could realistically result.
Consider:
- The sensitivity of the data
- Whether financial information was involved
- Whether passwords or authentication information were exposed
- Whether the data could enable fraud or identity theft
- Whether it contains confidential case information
- Whether children or vulnerable people are involved
- Whether safeguarding information was stored
- Whether the information could cause discrimination, distress or reputational harm
- Whether the data was encrypted or otherwise protected
- How easily affected individuals could be identified
A breach involving a small number of highly sensitive records may present more risk than one involving thousands of basic contact details.
The assessment should be based on your actual data and the possible impact on real people.
Decide Whether the ICO Must Be Informed
Under UK data protection rules, organisations must assess whether a personal data breach creates a risk to people’s rights and freedoms.
Where reporting is required, the ICO generally expects notification without undue delay and, where feasible, within 72 hours of awareness.
The 72-hour period is not necessarily measured from the moment the supplier completed its investigation.
It may begin when your organisation becomes aware that a personal data breach has occurred.
When information is incomplete, an initial notification can be updated as further details become available.
The ICO also provides guidance and a self-assessment tool to help organisations consider whether notification is required.
Even when the organisation decides that the ICO does not need to be informed, the breach and the decision should still be documented.
Record:
- What information was available
- What data was involved
- What risks were considered
- Who took part in the decision
- Why reporting was or was not considered necessary
Where the position is unclear, seek appropriate data protection or legal advice.
Consider Your Charity Regulator and Other Stakeholders
For charities, an ICO decision may not be the only regulatory consideration.
A serious incident report to the relevant charity regulator is a separate issue with its own threshold.
In Scotland, trustees should consider whether reporting to the Office of the Scottish Charity Regulator is necessary.
Charities operating elsewhere in the UK may need to consider the Charity Commission for England and Wales or the Charity Commission for Northern Ireland.
The board or trustees should be involved early because responsibility for charity governance rests with them.
Other parties may also need to be informed, including:
- Funders
- Local authorities
- Commissioning bodies
- Insurance providers
- Delivery partners
- Contractual partners
- Cyber insurance incident-response services
Check contracts and grant agreements for notification clauses.
Some may require incidents to be reported within a particular period, even where regulatory reporting is not required.
Decide Whether Affected Individuals Need to Be Contacted
Not every breach reported to the ICO requires a mass email to everyone in the database.
Direct notification to affected individuals generally applies where the incident is likely to create a high risk to their rights and freedoms.
Communicating too early or too widely can create unnecessary alarm and overwhelm the organisation with questions.
Communicating too late—or minimising a serious incident—can damage trust.
When people do need to be told, use plain language.
Explain:
- What happened
- When it happened
- What categories of their information were involved
- What the realistic risks are
- What the organisation has done
- What the supplier is doing
- What actions the individual should take
- How they can ask questions or obtain support
Avoid jargon, speculation and vague reassurance.
Do not say there is “no risk” unless that conclusion can genuinely be supported.
Communicate Internally Before Questions Arrive
Trustees, senior leaders, staff and relevant volunteers need consistent information.
Frontline employees should know what to say if a supporter, client or partner gets in touch.
Give them a short approved response covering:
- What is known
- What remains under investigation
- Where questions should be directed
- What they must not speculate about
- Who is authorised to speak publicly
This prevents contradictory answers and reduces the chance of inaccurate information being shared.
Internal communication should also make clear that only the designated incident team should contact the supplier or regulator.
Watch for Secondary Attacks
After a publicised supplier breach, criminals may impersonate the supplier or affected organisation.
Employees and customers could receive convincing messages claiming that they must:
- Reset a password
- Confirm account details
- Open a security report
- Download an updated application
- Verify banking information
- Make an urgent payment
Warn employees about this possibility.
Tell them where genuine updates will come from and how they can verify any unexpected request.
This is especially important where the affected supplier is widely used across the charity or nonprofit sector.
Review What the Incident Reveals About Your Supply Chain
Once the immediate response has been stabilised, review what the incident has exposed about your organisation’s dependence on third parties.
Start by creating an accurate supplier and data register.
For each provider, identify:
- What personal data it holds
- Why it holds that information
- Where the information is stored
- Which integrations are connected
- Who owns the relationship internally
- Whether multi-factor authentication is enforced
- What the contract says about breach notification
- How data can be exported or recovered
- What happens when the contract ends
- Whether the supplier has appropriate security assurances
Many organisations discover during an incident that more suppliers hold personal data than they realised.
CRM platforms, payroll services, cloud storage, email tools, website plugins, payment systems and marketing applications can all become part of the data supply chain.
The original notification highlights this broader lesson: an organisation’s data protection posture is partly dependent on the suppliers it selects and manages.
Questions to Ask Your CRM Provider
As the investigation develops, ask focused questions:
- What happened, and when did it begin?
- When was the incident detected?
- Which systems were affected?
- Was our organisation’s data accessed, copied, altered or deleted?
- What categories of data were involved?
- How many of our records may be affected?
- Were passwords, credentials, API keys or tokens involved?
- Was the information encrypted?
- Has the attacker’s access been removed?
- What containment and recovery actions have been completed?
- Has the incident been independently investigated?
- What evidence or documentation will be provided to customers?
- What actions must we take immediately?
- Will further updates be issued, and when?
- What will change to reduce the chance of recurrence?
Do not allow the response to become stalled while waiting for every answer.
Record unanswered questions and update the risk assessment as information becomes available.
Build a Better Response Plan for Next Time
No organisation wants to experience a supplier breach.
However, an incident can reveal exactly where processes need to improve.
When the immediate situation is over:
- Update the incident response plan
- Record the lessons learned
- Review supplier contracts
- Test staff contact procedures
- Confirm regulatory responsibilities
- Remove unused integrations
- Rotate credentials where appropriate
- Enforce multi-factor authentication
- Review user access and permissions
- Test backups and data exports
- Run a tabletop incident exercise
- Brief trustees and senior leaders
The purpose is not to create a perfect plan that anticipates every possible event.
It is to ensure that, when something happens, people know who takes charge and what the first steps are.
Final Thoughts
When a CRM provider experiences a security incident, the supplier must investigate and respond.
But your organisation still owns the decisions relating to its people, its data and its regulatory responsibilities.
The most effective response combines:
- Immediate technical containment
- Clear leadership
- Evidence-based risk assessment
- Appropriate regulatory reporting
- Honest communication
- Strong documentation
- A review of wider supplier risk
A third-party breach is a reminder that cybersecurity does not stop at the edge of your own network.
Every organisation holding your data becomes part of your security environment.
The time to understand those relationships is before an incident—not during one.
This article provides general information and is not legal advice. Organisations that are uncertain about their obligations should contact the ICO or seek appropriate professional advice.
Related Posts
What Does a Strategic vCIO Do for a Growing Business and Is It Worth It?
How Much Should Managed IT Support Cost for a 10-100 Employee Business in Scotland?
How Much Cybersecurity Protection Does a 50-Person Business Actually Need?
What Cyber Essentials Requirements Apply to Scottish SMEs and Charities in 2026?
