A CRM will fail at some point. An integration stops syncing overnight. A batch update overwrites months of Gift Aid declarations. A migration script does something nobody tested for. This happens to well-run databases as often as neglected ones, because the causes are rarely about how careful anyone was. The real difference between organisations is not whether something breaks. It’s whether anyone knows what to do in the first ten minutes.
Why “we’ll figure it out” isn’t a plan
Most charities don’t have a documented incident response process for their CRM or data systems. What they have instead is one person who knows how everything fits together, and a general assumption that if something goes wrong, that person will sort it.
This works right up until it doesn’t. The person with the knowledge is on leave, or has left the organisation, or is the person who caused the problem and is now troubleshooting under pressure with no second opinion. Decisions made in a panic tend to make things worse: restoring the wrong backup, switching off the wrong integration, telling the wrong people the wrong thing.
None of this is really about the technology. It’s about not having agreed, in advance, what a bad day looks like and who does what when it arrives.
What actually counts as an incident
Not every data problem needs this process. It helps to be specific about what triggers it, rather than treating every glitch the same way:
- An integration between your CRM and another system, finance, Engaging Networks, your website, stops passing data, silently or otherwise
- A bulk update, import or migration hits the wrong records, or an unknown number of records
- Data goes missing or looks corrupted and you can’t immediately explain why
- You suspect a security or data protection issue, which should trigger your data breach procedure alongside this one, not instead of it
If more than a handful of records are affected, or you can’t yet tell how many are, treat it as an incident and start the process below rather than trying to quietly fix it first.
The five steps
Stop and scope. Before fixing anything, work out what’s affected and when it started. Find the last point you know was correct. Resist the urge to start correcting records before you understand the full picture, you may be about to fix the same problem twice, or hide evidence of what went wrong.
Contain. Pause whatever could make it worse: the integration, the import job, the campaign send. It’s easier to restart something paused than to undo something that ran again while you were investigating.
Communicate. Tell the right people immediately, not after you’ve tried to fix it yourself. That usually means your line manager, whoever manages the affected system, internal IT or the vendor, and, if supporters or donations are affected, your fundraising or communications lead. Agree one person who owns updates, so the organisation isn’t getting three versions of what’s happening.
Fix and verify. Restore from backup or correct the records, then check the fix against a second source before you declare it resolved. A fix that looks right in the CRM but doesn’t reconcile with your finance system or your email platform isn’t finished yet.
Debrief and document. Once it’s resolved, write down what happened, why, and what you’re changing so it’s less likely to happen the same way again. This is the step charities skip most often, and it’s the one that actually reduces how often you end up back here.
Building the plan before you need it
A response plan is only useful if it exists before the incident does. Three things make the biggest difference.
Know your backup and restore process properly, not just that backups are scheduled. Know how recent your last genuinely clean backup is, and how long a restore actually takes, before you need that answer under pressure.
Map your integrations. If you’re on Raiser’s Edge NXT, BeaconCRM, Access Charity CRM, thankQ or Oomi, know exactly what else talks to it, Engaging Networks, your finance system, your email platform, so you can work out the blast radius of a failure in minutes rather than hours.
Name a decision maker for when the usual person isn’t available. The plan should work even if the one person who “knows the system” is on annual leave.
None of this requires new software or a big project. It requires deciding, in a calm moment, what a bad moment will look like and who does what. That decision is far easier to make on an ordinary Tuesday than in the middle of a crisis.
If you want a second opinion on how ready your organisation actually is, get in touch with Actually Data Analytics for a data resilience review. We’ll look at your backups, your integration map and your response process, and tell you honestly where the gaps are.