Why backups matter
- Because you want to
Most data lives "in the cloud". That means: "on someone else's server." Accidental deletion, a compromised account, a vendor outage, or an employee leaving with the wrong access can all cause data loss. Backups are not about distrust — they're about making sure that for every system that matters, you have a copy somewhere you own.
- Because you have to
An expired backup that falls short of the legal minimum is a compliance risk, not just a data risk:
Legal retention periods (Netherlands)
- Financial records: 7 years (wettelijke bewaarplicht)
- HR / employment records: 5–7 years after end of employment
- Donor / personal data: per your privacy policy + AVG/GDPR; retain only as long as necessary, but ensure you can reproduce records if audited
Step 1: Know what you're protecting
Before setting up backups, map your critical data. You can't protect what you haven't inventoried.
List your critical systems and data sources one-off
Which systems hold data you can't function without? E.g. donor database, email, financial records, website, document storage.
Classify by impact one-off
For each system: what happens if it's unavailable for 1 hour / 1 day / 1 week? This sets your recovery priority.
Identify the data owner for each system one-off
One named person responsible per system.
Step 2: Set up backups
The 3-2-1 rule is the classic backup standard: 3 copies of important data, on 2 different media types, with 1 copy offsite or in a separate cloud account. For a 5–15 person org running entirely on SaaS tools, that's overkill.
Our recommendation: keep at least one copy of each critical dataset somewhere you control, outside the original vendor — something you could fall back on if the vendor disappeared tomorrow. In practice: an annual export to a restricted Drive folder, or monthly for donor data.
✳️ One-off checks
Google Workspace: Enable a third-party backup tool one-off
Google has no native backup tool. Vault (Business Starter+) handles compliance retention but can't restore a mailbox to a point in time. For real backup and restore of Drive and Gmail, use Backupify or Spanning. Without one, your only safety net is the 30-day deletion window in the Admin console.
Google Workspace: Confirm shared drives are in scope one-off
Personal drives and shared drives are separate — check both are covered.
Website: Confirm your hosting provider takes daily backups one-off
Most managed WordPress hosts (Kinsta, WP Engine, SiteGround) include daily backups — verify this and know how to trigger a restore. If using Webflow or another SaaS CMS, check the platform's versioning and export options: these vary significantly.
CRM/donor database: Check whether your CRM supports export one-off
Most SaaS CRMs (HubSpot, Salesforce, Donorbox, etc.) allow CSV or JSON exports. If your organisation uses a custom-built donor database, confirm automated database backups are configured on the hosting provider: daily frequency, at least 30 days retention, stored separately from the primary server.
Slack: Check your export options and set expectations one-off
Slack is not a system of record. On free and Pro plans, message history is limited and not fully exportable. On Business+ and above, admins can export all messages. Either way: decisions and outputs belong in Slite or Asana, not Slack.
🔄 Recurring back-ups
CRM/donor database: Run a recurring export monthly
Even with automated backups, a manual export to a restricted Drive folder adds a layer of protection — and gives you something portable if you ever switch CRMs.
- Export from Donorbox
- Export from Hubspot
- Export from Mailerlite
- Export from Asana (One caveat on Asana worth noting: the CSV export is per-project and doesn't include task history, comments, or attachments. For a CRM backup, the CSV gives you the data fields but not the full activity log.)
Financial records: Export administration annually (at year-end)
At year-end, either your accountant pulls a full export as part of close (confirm this with them and verify you have access), or do it yourself. Required for the 7-year bewaarplicht.
Remote: Download contracts and payslips annually
Remote manages its own infrastructure backups. Your responsibility: download employment contracts and payslips to a restricted Drive folder once a year. These records must be retained for 5–7 years after end of employment (see legal retention periods above).
Slite: Export the full workspace annually
Slite is your primary knowledge base — losing it would be disruptive. Request a backup of your workspace content. Store the export in a restricted Drive folder.
Website/CMS: Take a manual backup before any major change
Before updating plugins, changing themes, or migrating: take a snapshot.
Remote: Download contracts and payslips at offboarding
Always download and store a departing employee's contract and payslips before closing their account in Remote. Make sure this is captured on the offboarding checklist so it actually gets done.
No action required
- Asana: Operational, not archival. Deleted projects and tasks can be recovered within 30 days via Trash. Anything worth keeping long-term should be saved to Slite or Drive at the time of creation.
- Exception: when you use Asana as your CRM/donor database
- Claude: Conversations are not a system of record. Any output worth keeping should be saved to Slite, Drive, or Asana at the time of creation. Claude has no persistent storage to back up.
Step 3: Test your recovery
Untested backups are not backups. Most organisations discover their backups don't work when they need them. Don't skip this section.
Do a test restore for each critical system annually
Pick one file, one record, or one snapshot — and actually restore it.
Time the restore annually
How long did it take? That's your Recovery Time Objective (RTO) — the realistic answer to "how long will we be down?"
Document the restore procedure after first successful test
Write it in plain language: where backups are stored, who has access, what tool to use. Keep a copy somewhere accessible even if your main systems are down.
Step 4: Access & security of backups
Restrict access to backup files one-off
Backups containing personal data must be limited to authorised staff. Same access rules as the original data.
Store backup credentials in your password manager one-off
Proton Pass, not a shared doc or personal notes.
Check that backups are encrypted one-off
Most cloud providers encrypt at rest by default — verify. For manual exports in Drive: restrict sharing, no "Anyone with link".
Configure emergency access one-off
Set up an admin recovery contact in your password manager. Document who holds it and how to invoke it.
Include backup access in your offboarding procedure one-off
When someone leaves, revoke their access to backup storage and the password manager before closing their account.