Read our blog

In short: Removing a user is three different actions (deactivate, remove, delete) and each platform keeps a different amount of their work. ClickUp deletes private Folders, Lists and tasks on removal; Asana, monday.com and HubSpot keep content but leave ownership, automations or assignments for you to fix. A snapshot taken before removal is the only copy you fully control.

Someone hands in their notice. IT revokes their login on Friday afternoon. On Monday a project manager asks where the client's onboarding checklist went, and the answer is "it was in a private List that no longer exists."

This post compares what four platforms actually do with a departing user's data, then gives you a checklist that puts the export and reassignment steps before the click that cannot be undone.

Deactivate, remove or delete: the three actions and what each keeps

Vendors use the words loosely, so it helps to separate them:

• Deactivate blocks the login and frees the seat, but the account record stays. Usually reversible.
• Remove / deprovision takes the person out of the workspace or organisation. Their content may or may not survive.
• Delete wipes the user's identity. On the platforms below this is irreversible.

Two patterns stand out. Every platform keeps public work. What differs is the fate of private work and of the things a person owns rather than creates: automations, integrations, board ownership, connected inboxes.

Asana: tasks are gathered, ownership is not transferred

When a user is deactivated, "whether through an identity provider like Okta or manually via the admin console", Asana generates a project holding the tasks that were assigned to them. Super admins become members of that project, and the super admin chosen as owner receives a review task. (Source: Asana user deprovisioning, checked 2026-09-16.)

What the same article does not promise is ownership transfer: "Deactivation does not currently transfer data ownership for projects, portfolios or dashboards." If the leaver was the only member of a private project, add a second member with edit access before you deprovision. Deleted tasks and projects can still be recovered from Deleted items for 30 days, after which they are permanently deleted (Asana: Recover deleted items, checked 2026-09-16).

ClickUp: private work is deleted on removal

ClickUp is the strictest of the four. Removal is permanent, and the help centre states plainly that "Private Folders, Lists, and tasks owned by a deactivated person will be deleted and removed when they leave the Workspace." Public items remain, with the person still shown as assignee under a "Deactivated" label, and any Automation they created stays active. (ClickUp: Remove someone from a Workspace, checked 2026-09-16.)

Do not count on the Trash to catch this. Workspace owners and admins "can see, restore, or permanently delete any public items. They do not have access to private items" (ClickUp: Restore items from the Trash, checked 2026-09-16). Ask the leaver to share or move private Lists to a public location before their last day.

monday.com: deactivate first, transfer everything, delete last

monday.com separates deactivation from deletion. A deactivated user loses access and stops counting towards paid seats, but "will still be assigned to the tasks they were assigned to, and their updates posted will remain on items". Before you confirm, a prompt warns that their automations and integrations will be disabled and asks you to choose a new owner. If they were the sole owner of private or shareable boards, those boards "will become inaccessible" until an admin transfers ownership in the Administration section. (monday.com: How to manage users, checked 2026-09-16.)

The dedicated handover article walks through the order: board ownership, automation ownership, integration ownership, dashboard ownership, then deactivate. Its tip for SCIM users matters: complete those steps before the identity provider deactivates the account automatically (monday.com: What to do when a member leaves your account, checked 2026-09-16).

Permanent deletion is a second step after deactivation and "is irreversible". The content stays, shown under a grey icon as "Deleted member".

HubSpot: nothing is deleted, but records go unowned

HubSpot keeps the most. Whether you deactivate or remove a user, "HubSpot will not delete any assets or activities that they created", down to logged emails and notes. The risk is different: ownership. A deactivated user stays the owner of their contacts, companies, deals and tickets, and a removed user leaves "Deactivated/Removed (email)" in the owner property. HubSpot recommends reassigning records before either action. Their connected inbox is disconnected, so any scheduled sequence emails stop sending. (HubSpot: Deactivate and remove HubSpot users, checked 2026-09-16.)

Deleted records, if the leaver cleaned house on the way out, can be restored from the recycle bin for 90 days (HubSpot: Restore deleted records, checked 2026-09-16).

A 6-step offboarding checklist

Work through these in order. Steps 1 to 3 happen while the person still has access; step 4 is the point of no return.

1. Reassign. Filter every task, item or record where the leaver is assignee or owner and reassign it. ClickUp's Bulk Action Toolbar, monday.com's Board Ownership tab and HubSpot's owner filter ("show inactive owners") all do this in bulk. In Asana, check the auto-generated project after deprovisioning as well.
2. Export or snapshot before removal. Take a copy of the workspace as it is today, including the leaver's private Lists, boards and projects. If you run a daily backup, confirm the last snapshot completed after their final edits and before you remove them.
3. Transfer ownership of automations, integrations and OAuth apps. monday.com prompts for automation and integration ownership at deactivation; ClickUp keeps Automations running but check any that post to the leaver's channels; HubSpot workflows survive but sequences tied to their inbox stop. Revoke or re-authorise any third-party app that was connected with their personal login, including your backup tool if they were the connecting user.
4. Revoke. Deactivate first where the platform offers it (monday.com, HubSpot, Asana licence pause). Delete only after a cooling-off period, because delete is irreversible on every platform above.
5. Verify. Open a project, board or record they owned and confirm someone else can edit it. Trigger one of their automations. Check that shared inbox rules and integrations still fire.
6. Document. Record what was reassigned, what was exported, who now owns which automation, and the date of the last good snapshot. Your auditor and your future self will both ask.

For a broader view of the deletion controls each platform gives admins, see how to restrict deletions in your SaaS apps.

Where a backup fits

Every native mechanism above is scoped to what the platform decides to keep. ClickUp deletes private work outright; Asana and monday.com keep it but may leave it without an owner; HubSpot keeps it but leaves records orphaned. None of them lets you look at the workspace as it was the week before the person left.

ProBackup takes a snapshot of each connected platform every 24 hours and stores it independently, encrypted with AES-256 at rest and TLS in transit, in the AWS region you selected at signup. Snapshots are kept for 6 months on Plus, 2 years on Pro and without limit on Premium.

For offboarding that means:

• Private work stays in the backup. Private tasks and projects of a user who leaves the platform remain in the ProBackup backup and stay visible to the ProBackup admin. A ClickUp private List that the platform deleted on removal is still in yesterday's snapshot.
• Point-in-time restore. You can restore a project, board or List as it was on any snapshot date before the departure, not just recover what happened to survive the removal.
• Two restore modes. Create new duplicate records (safe, leaves originals untouched), or overwrite existing records field by field. Overwrite mode is available for HubSpot, ClickUp, Asana, monday.com, Airtable and Attio; calculated fields such as system fields, formulas and relations are excluded; there is no per-restore record limit.

Restores go back to the original account only. ProBackup is a backup tool, not a migration tool.

Platform trash bins help with plain deletions but not with ownership gaps or private-item removal; we compared their windows in SaaS recycle bins: why they won't save you and version history and trash retention across SaaS apps.

See the platform pages for scope and setup: Asana, ClickUp, monday.com and HubSpot, or the overview for IT admins.

Frequently asked questions

Does deactivating a user delete their data?

Not on Asana, monday.com or HubSpot: tasks, items, records and posted updates stay, though ownership and automations may need transferring. On ClickUp, removal deletes the person's private Folders, Lists and tasks, while public items remain. Check the platform table above before you click.

Can an admin see a former employee's private projects?

Only if the platform keeps them and gives admins a path in. Asana super admins become members of the auto-generated project of the leaver's assigned tasks but do not inherit ownership of private projects. ClickUp admins cannot access private items, including in the Trash. In a ProBackup backup, private tasks and projects of a departed user remain visible to the ProBackup admin.

How long do I have to recover something the leaver deleted?

Asana Deleted items: 30 days. ClickUp Trash: 30 days. monday.com Trash: 30 days. HubSpot recycle bin: 90 days. All figures from the platforms' own help centres, checked 2026-09-16. After the window the item is permanently deleted.

What should I do if the leaver was the person who connected our integrations?

Re-authorise each integration with a service account or another admin before their login is revoked. monday.com deactivates the leaver's integrations and prompts for a new owner; HubSpot disconnects their personal inbox, which stops scheduled sequences. This applies to your backup connection too: if the departing user authorised ProBackup, reconnect it with an account that will outlast them.

Protect the work before the account goes

ProBackup takes daily snapshots of Asana, ClickUp, monday.com and HubSpot and is trusted by 4,000+ teams. Plans start at $25 per month, billed yearly.

Start your free 7-day trial - no credit card required.

In short: ProBackup has been SOC 2 Type II certified since May 2025. The latest report covers 1 April to 30 June 2026 and can be requested through the trust centre at trust.probackup.io. It evidences how ProBackup protects the backup data it holds. It is not an ISO 27001 certificate, and it does not make your own organisation compliant with anything.

If you are evaluating a backup vendor, someone in procurement or security will ask for the SOC 2 report. This page explains what ours covers, how to get it, and what it does not prove.

What SOC 2 is (and is not)

SOC 2 is an attestation framework published by the AICPA, the American Institute of Certified Public Accountants. An independent auditor examines a service organisation's controls against the Trust Services Criteria (TSC), which cover five categories: security, availability, processing integrity, confidentiality and privacy. Security is mandatory; the other four are included when relevant to the service.

Two report types exist. A Type I report assesses whether controls are suitably designed at a single point in time. A Type II report assesses whether those controls operated effectively across a review period, typically several months. Type II is the one that matters for a vendor you will rely on continuously, because it shows the controls held up over time rather than on the day of the audit.

SOC 2 is not a regulation and not a certificate in the ISO sense. The output is an auditor's report with an opinion, which is why the precise wording is "SOC 2 Type II report" or "SOC 2 Type II certified". The substance is in the report's scope, the auditor's opinion and any exceptions listed, not in a logo.

ProBackup's report: dates and scope

• Certified since: May 2025, when ProBackup's first SOC 2 Type II report was issued.
• Latest report period: 1 April 2026 to 30 June 2026. Reports are renewed on a rolling basis, so this line is updated whenever a new period is issued.
• Scope: the ProBackup service that takes daily snapshots of connected cloud apps, stores them and restores them. Controls cover the infrastructure (AWS, with S3 storage in one of nine regions selected by the customer), encryption (AES-256 at rest, TLS in transit), access control (two-factor authentication for users, SSO on Premium, MFA and least-privilege access for ProBackup staff), change management, monitoring, vendor management and incident response.
• Related evidence: an annual third-party penetration test report and the Data Processing Addendum sit alongside the SOC 2 report.

Which criteria relate to backup and availability

Buyers of a backup service usually care about three areas of the TSC. Described generically, per the AICPA's criteria:

• CC7.5 (Security, "System operations") asks whether the organisation identifies, develops and implements activities to recover from identified security incidents. For ProBackup this is the incident-response and recovery procedure for the backup platform itself.
• A1.2 (Availability) asks whether environmental protections, software, data backup processes and recovery infrastructure are authorised, designed, developed, implemented, operated, monitored and maintained to meet availability objectives. This is where the auditor looks at how ProBackup's own systems and stored snapshots are protected and replicated.
• A1.3 (Availability) asks whether recovery plan procedures are tested to meet availability objectives. In plain terms: not just having a recovery plan, but exercising it.

Together these answer "if ProBackup has a bad day, is the backup copy of my data still safe and recoverable?" They cannot answer "is my Asana workspace backed up?" That is your control, covered below.

How to request the report

1. Go to the trust centre at trust.probackup.io (hosted on Comp AI). It lists the SOC 2 Type II and GDPR status, the policies and controls in scope, the penetration test summary and the DPA.
2. Click Request access, fill in your details and accept the non-disclosure terms. SOC 2 reports contain detail about an organisation's environment, so they are shared under NDA, which is standard practice.
3. Once approved you can download the current report, and you will have access to later reports as they are issued.

The documents are also listed on the audit reports page, and the data security page summarises the controls in plain language. Security questionnaires can be sent to support and are answered from the same evidence base.

What ProBackup does not hold: ISO 27001

ProBackup does not hold ISO/IEC 27001 certification, and we do not claim it. If a questionnaire asks, the honest answer is "SOC 2 Type II, not ISO 27001".

The two frameworks overlap heavily but are not interchangeable. ISO/IEC 27001:2022 certifies an information security management system against a fixed set of requirements, with Annex A listing reference controls. The relevant one here is Annex A 8.13, Information backup, which expects backup copies of information, software and systems to be maintained and regularly tested in line with an agreed backup policy. SOC 2's availability criteria ask a closely related question in a different form; neither substitutes for the other on a questionnaire. If your organisation requires ISO 27001 from every processor, ProBackup will not meet that line item today, and we would rather you know before procurement than after.

Pulling ProBackup evidence into your own audit with Vanta

If your organisation runs its own SOC 2 programme on Vanta, ProBackup's integration lets Vanta test your ProBackup account automatically rather than relying on a screenshot at audit time. In the Vanta Integrations section, connect your ProBackup account; Vanta then runs three continuous tests:

• Accounts deprovisioned when personnel leave: ProBackup users belonging to departed staff are removed.
• User accounts associated with users: every ProBackup login maps to a named person, so there are no orphaned accounts.
• User accounts have MFA enabled: two-factor authentication is switched on for each ProBackup user.

Those tests feed Vanta controls such as remote-access MFA enforcement and unique authentication. They are evidence about your use of ProBackup, the part a vendor's own report cannot supply. Background: the Vanta integration announcement.

How a vendor's report differs from your compliance

This is the point most often misunderstood. ProBackup's SOC 2 Type II report proves that ProBackup, as a processor, protects the data it holds. Under GDPR Article 28 that is the kind of "sufficient guarantee" you are required to check before using a processor. It does not transfer your obligations to us.

Your own auditor will still ask you to show:

• That backups exist for the systems in scope. Which apps are connected, since when, and who owns the configuration.
• That retention matches policy. Version history is 6 months on Plus, 2 years on Pro and unlimited on Premium; the plan you chose should match the retention your policy states. A written SaaS data backup policy is where that decision lives.
• That restores are tested. A restore drill per quarter, with a note of what was restored and how long it took, satisfies the "tested" element in both SOC 2 A1.3 and ISO 27001 A 8.13.
• That access is controlled. Who can open the vault, who can restore, whether MFA is on. The Vanta tests above cover this automatically.

NIS2 follows the same logic for in-scope entities: the backup and recovery obligation sits with the organisation, and a processor's report is supporting evidence. See NIS2 backup requirements, and the GDPR page for how ProBackup handles personal data as a processor.

FAQ

Is ProBackup SOC 2 certified?

Yes. ProBackup has been SOC 2 Type II certified since May 2025. The latest report period is 1 April to 30 June 2026, and reports are renewed on a rolling basis.

How do I get ProBackup's SOC 2 report?

Request it at trust.probackup.io. Access is granted under NDA, after which you can download the current report and the penetration test summary and DPA.

Is ProBackup ISO 27001 certified?

No. ProBackup holds a SOC 2 Type II report, not ISO 27001. The frameworks overlap, but if your policy requires ISO 27001 from every processor, ProBackup does not meet that line item.

Does using a SOC 2 certified backup vendor make my company SOC 2 compliant?

No. Our report evidences how we protect the data we hold. Your own audit still needs to show which systems are backed up, that retention matches your policy, that restores are tested and that access is controlled; the Vanta integration automates part of that evidence.

Week one: the cron job runs, the files land in the bucket, and Slack gets a green tick every morning. Week six: same green tick. Nobody opens the files, because why would you. Then someone deletes a ClickUp space by mistake, the team opens the bucket, and the "backups" turn out to be six weeks of empty API responses. The tool had been reporting success since the day the platform changed an endpoint.

That is a lightly anonymised version of a story a returning customer told us this summer. Over the past few months, several teams cancelled their ProBackup subscription with the same reason: "we vibe coded our own backup tool." One of them is now back.

We get the appeal. Prompt Lovable or Claude to "build a tool that backs up our ClickUp workspace every night" and twenty minutes later it works. The data lands in a bucket, the cron job runs, and the internal message writes itself: we just saved ourselves a SaaS subscription. But a backup tool is the one piece of software in your stack that only matters on its worst day, and a vibe-coded backup has usually never seen a worst day.

This post covers what vibe coding platforms do well, why backup is a special case, what a backup subscription actually buys, and an honest cost comparison between building and buying. The short answer to the question in the title: the danger isn't that AI writes bad code. It's that nobody ever tests the restore.

Vibe coding platforms are impressive, and getting better

Let's start with credit where it's due, because this isn't an "AI code bad" post.

Vibe coding, the practice of describing what you want in natural language and letting an AI agent write the software, has matured fast. Lovable's Agent can browse websites, search the web, and update code across multiple files at once, acting more like a developer working alongside you than an autocomplete. In May 2026 Lovable added AI subagents, including a Reviewer, that run in parallel during a build, and the platform now ships native Wiz security scanning, with findings surfacing in every project's Security view. In July 2026 Lovable became the first AI coding platform to achieve AIUC-1, a security and reliability standard built for AI agents.

That's real progress, and the productivity gains are real too. For internal dashboards, prototypes, landing pages, and your personal note-taking app, these tools are hard to beat. The question is not whether vibe coding works. It's whether a backup tool is the right thing to vibe code.

Why backup tools are a special case

A backup tool isn't a photocopier you run once. It's a system that has to notice and keep up with tens of millions of moving pieces every day, quietly, forever. That gives it an unusual property: it can fail silently for months and look completely healthy.

A healthy-looking backup and a complete backup are different things. The cron job running proves that the cron job ran. Real confidence comes from watching the data itself: noticing when a record type quietly stops flowing in, or suddenly doubles, or when a field that used to be populated is now blank across the board. That monitoring layer is invisible, boring, and almost never gets built in a weekend, which is exactly why DIY backups fail silently.

The scariest version of this risk is quiet deprecation. Platforms retire fields and endpoints with an announcement in an email nobody reads. The DIY tool keeps reporting success while a slice of your data stops arriving. You're sitting on an incomplete backup, and you'll find out on the one day it matters.

Scale does the same thing more slowly. A DIY backup that works on the demo workspace often collapses on the real one: API rate limits, accounts with hundreds of thousands of records, and the need to back up only what changed each night instead of everything. Getting that right is unglamorous engineering that never fits in a prompt.

Under the shared responsibility model (the standard SaaS arrangement where the vendor protects the platform and you are responsible for your own account data), that gap is yours to own. If your homegrown tool quietly broke, there is no vendor to call.

The risks, in the order they'll bite you

The research on AI-generated code is no longer anecdotal. Veracode's 2025 code security report found AI-assisted pull requests produced 2.74 times more security issues than human-written code; a 2026 GitGuardian report found AI-assisted commits leaked secrets such as API keys more than twice as often; a Cloud Security Alliance note from April 2026 found nearly one in five AI-generated code samples referenced a package that doesn't exist, names attackers now register in advance (a technique called slopsquatting); and Georgia Tech's Vibe Security Radar attributed 35 CVEs to AI coding tools in March 2026 alone. A backup tool holds admin-level API tokens for your most important systems, so every one of those findings lands harder here than it would on a landing page.

But the statistics aren't what kills homegrown backups. The stories are.

1. Nobody maintains it. Ask one question: which engineer's name is next to "owns the backup"? For vibe-coded tools the honest answer is usually nobody. The author changed roles, the codebase is a chat transcript, and the platforms it connects to keep moving.
2. The restore is never tested. Copying data out is the easy half. Putting it back, with hierarchy, relationships, comments, custom fields and permissions intact, is the hard half, and it's the half a weekend build almost never includes. A backup you can't restore from is a storage bill.
3. False confidence. The most dangerous property of vibe-coded software is that it looks finished. It demos well. The one scenario that would expose it, a real disaster, is the one you can't rehearse by accident.
4. The odds of needing it are going up. The same AI wave that produces vibe-coded tools is putting AI agents inside ClickUp, HubSpot and Notion, creating, editing and bulk-deleting at machine speed. Teams are being tempted to downgrade their backup at exactly the moment they're most likely to need it.
5. The watchman has no watchman. Your backup is the safety net under every other tool. If the safety net itself is the least-tested, least-owned, least-monitored piece of software in the company, you don't have a safety net. You have a feeling.

What a dedicated backup vendor actually does all day

ProBackup is a SaaS backup service that takes automated daily snapshots of your cloud app data and lets you restore individual records, files or whole projects back to the original account. That sentence hides a lot of work, so here is what the subscription pays for:

Continuous integration maintenance. We back up 20 platforms, and right now every one of them is rolling out features and API changes at the fastest pace we've seen. When ClickUp adds a new field type or HubSpot versions an endpoint, updating the integration is our job that week, not a ticket in your backlog competing with actual product work.

Security as a discipline, not a feature. SOC 2 Type II certified since May 2025, GDPR compliant, AES-256 encryption at rest, TLS in transit, least-privilege API scopes, and nine AWS storage regions you choose at signup. No hardcoded tokens in a script someone pasted from a chat window.

A restore that's been through real disasters. Our restore paths cover the scenarios that actually happen: single-record recovery, full-space recovery after a malicious deletion, and point-in-time recovery (restoring data exactly as it was on a chosen date) after a bad sync or an agent gone wrong. You choose whether to restore as new duplicate records, leaving the originals untouched, or to overwrite existing records field by field. These paths get exercised constantly. In the last 30 days alone, 36 different teams hit the restore button, 94 times between them. Those restores put roughly 64,000 records back where they belonged, each in the right order, with relations rebuilt. The disaster you're insuring against isn't rare; for someone, it's today. Your DIY restore gets its first production test during your emergency.

The humans behind the product. Even after nine years of engineering, roughly one in a hundred restore steps hits something specific to that account: a quirk of their setup that the API refuses. That's when our support team, which has guided hundreds of restores across 4,000+ teams, steps in and finishes the job. A vibe-coded tool's support team is a chat history and whoever prompted it, if they still work there.

The cost breakdown: from $25 a month vs building it yourself

Assume a realistic DIY scenario: one technically capable team member, a vibe coding platform subscription, and a sincere intent to keep the thing alive.

Price out the person's time at even a modest internal rate and the DIY option costs more in month one than ProBackup costs in year one.

But that isn't the number to remember. This is: one bad day costs more than a multi-year subscription. When a DIY restore fails, you pay for several people from several teams spending days on manual re-entry, plus the business standing still while they do it. That's thousands of dollars against roughly $300 to $830 a year. Framed as insurance, which is what a backup is, the "savings" of DIY round to zero.

What good looks like

If you take one section from this post, take this one.

1. Vibe code freely for tools where failure is cheap: internal dashboards, prototypes, automations, your own note-taking app.
2. For anything that protects business-critical data, buy from a vendor whose entire business depends on the restore working, or commit to building with real engineering rigour: code review, dependency scanning, secret management, data-level monitoring and scheduled restore drills.
3. Whatever you choose, test a restore this quarter. Not an export. A restore.
4. Put a named owner next to "owns the backup". Then audit which API tokens your homegrown scripts hold today, and what happens to them when that person leaves.
5. Date your assumptions. An integration that worked "as of March" is not an integration that works.

Conclusion

Would you vibe code your fire insurance? Nobody disputes that AI can build the thing. The question is whether you want to depend on it on the worst day of your company's year.

The tension we opened with is real: vibe coding platforms are excellent and improving monthly, and the case against using them for backup keeps getting stronger. Both are true because they answer different questions. Lovable answers "can I build this?" with an increasingly confident yes. A backup tool answers "will this work when everything else has gone wrong?", and that question is answered by maintenance, monitoring, security discipline and restores tested dozens of times a month, none of which fit in a prompt.

There's a simpler way to say what a backup subscription is. You're not buying software. You're buying someone whose entire business fails if your restore fails. No vibe-coded tool has anyone whose livelihood depends on it working.

Build your next internal tool with AI. We probably will too. Just don't let the tool that guards everything else be the one nobody is maintaining. [Start your free trial] or [see which plan fits your team].

This post is written for IT admins, ops leads, and founders who are responsible for their organisation's data in SaaS tools, and who have at least once been tempted to just build it themselves.

In short: Before a SaaS platform migration, take an independent backup of the source platform 24 to 48 hours before any export, keep the source account live for at least 30 days after go-live, and verify data quality (not just record counts) against that backup before decommissioning. ProBackup restores only to the original platform instance: a rollback net, not a migration tool.

A client services manager moved her team from Trello to Asana last quarter. The migration tool worked cleanly: all 2,400 cards transferred, custom fields mapped correctly, due dates preserved. The Trello account was cancelled two weeks after go-live.

Six weeks later, a client asked for the decision trail on a project from eight months ago. The comment threads where the scope changes had been discussed, the back-and-forth over timelines, the approval messages. None of it had migrated. The migration tool had transferred card titles, descriptions, and fields. Comments weren't in scope.

The Trello account was gone. The only CSV export she had was the one she'd taken before the migration, which also didn't include comments. The data existed nowhere.

The data protection problem in a migration isn't the migration itself. Most migration tools work fine for structured records. The problem is the window: the period between "we're leaving Platform A" and "we're settled on Platform B" when your data exists in a half-migrated, half-connected state and your usual safety nets don't apply.

This post is about how to protect yourself in that window, and what to do if something goes wrong during or after the move.

✅ Good for: Teams moving between SaaS platforms who want an independent backup of the source platform before they start, and a rollback option if the migration loses or corrupts data.

‍
❌ Not for: Teams looking for a tool to migrate data between platforms. ProBackup restores data to the original platform instance, not to a different app or account. For that, you need a dedicated migration tool.

Why migrations are high-risk for data

A migration is the single moment in your SaaS lifecycle where more things can go wrong with your data than at any other time.

You're exporting from a live platform in active use, often while the team is still working in it. You're running imports into a new platform that behaves differently, has different field types, different required fields, different relationship structures. You may be doing this in stages, or running both platforms in parallel for weeks while the team transitions.

Each of these creates specific risks:

Data that doesn't survive the export. Most SaaS platforms export to CSV or their own proprietary format. Comments, activity history, nested structures, and file attachments rarely survive a CSV export intact. If your migration tool relies on the platform's native export rather than the API, you're already losing data before the move starts.

Data that imports but lands wrong. Field type mismatches silently corrupt data. A single-select field on Platform A becomes a text field on Platform B. Dates parse differently. Custom fields that don't have an equivalent on the new platform get dropped or flattened. The import completes without errors and the data looks fine on the surface, but something is wrong in a field your team uses every day.

Data that exists nowhere during the transition. If you export from Platform A and delete the records before confirming the import to Platform B went cleanly, you have a brief window where that data exists only in an unverified export file. If the import fails, you're restoring from that file, which may itself be incomplete.

The source platform gets decommissioned before problems are found. Someone notices six weeks after migration that a custom field didn't transfer. By then, the source platform account has been cancelled, the trial is expired, and the only copy of the original data is the export file from day one. This is the shared responsibility model in its starkest form: the migration tool did what it was supposed to do. What you lost was your own responsibility to protect.

Step 1: Back up the source platform before you start

This is the single most important thing you can do, and almost nobody does it deliberately.

Before you run a single export, before you install the migration tool, take a complete independent backup of the source platform. Not a CSV export. An independent snapshot stored separately from the platform, with its own authentication, that you can access even after the source account has been cancelled.

This is exactly what ProBackup is designed for. Connect the source platform, wait for the first snapshot to complete, and verify that the data is there. Now you have a clean, point-in-time backup of your data as it existed before the migration started. If the migration goes wrong two weeks from now, you can restore from this snapshot regardless of what's happened to the source account.

This backup has a specific value that no export file can provide: it's a complete, structured, searchable record of your data at a specific date. If you need to find out what a specific task's comments said on the day before the migration, or what a deal's field values were before the import overwrote them, the backup has it. The CSV export doesn't.

Step 2: Don't cancel the source platform until you've verified the migration

The impulse to cancel the source platform the day the migration completes is understandable. You're paying for two platforms, the team has moved, and keeping the old one running feels wasteful.

Resist it for at least 30 days.

Data problems from migrations are rarely found immediately. The team is adapting to the new platform, workflows are being rebuilt, and nobody is systematically checking that every field, every comment, every attachment landed correctly. The problems surface when someone tries to use the data: "Where's the history on this deal?" "The status field only has three options, it should have five." "The files on this project aren't loading."

Keep the source platform accessible for a minimum of 30 days post-migration. If you had ProBackup connected, you also have the backup vault to reference even after the account is cancelled, which covers you beyond 30 days for as long as your retention period runs. On a Plus plan that's six months, on Pro it's two years. That's the window within which you can go back and find what the data looked like before the migration. It's also worth noting that the source platform's native recycle bin won't help here: if the account is cancelled, the recycle bin goes with it.

Step 3: Verify the migration before you decommission anything

Before you cancel the source platform, run a structured verification. Don't just look at record counts. Check the data quality in the new platform against the backup of the old one.

A practical verification checklist:

• Record count: Export the relevant workspace from the ProBackup vault as an Excel file and compare the row count against the equivalent view on the new platform. A discrepancy of even a few records usually indicates dropped items.
• Field values: Pick ten records at random and open them side by side: the vault view on the source platform and the live record on the new platform. Check every field value. Pay particular attention to single-select and multi-select fields, which are most likely to have lost options during the schema mapping.
• Comments and activity history: In the ProBackup vault, navigate to three or four records that had significant comment threads and check the Comments tab. Compare what's there against the new platform. Comments are the most commonly lost data type in migrations because many export formats don't include them.
• File attachments: Open the Attachments tab in the vault for the source platform and compare against the new platform. Try loading ten files on the new platform. If the migration tool linked to the old platform's file storage rather than copying the files, links will break the moment you cancel the source account.
• Custom fields: Export a complete data table from the vault and open it in Excel. Check that every column header corresponds to a field on the new platform, and that none of the expected columns are blank across all rows.
• Relational data: If your source platform had linked records, parent-child relationships, or dependencies, check a sample of these specifically. They're the most likely data type to be silently dropped or flattened during schema transformation.

Document the verification results. If problems are found, you still have the source platform running and the backup vault to restore from. If the verification passes cleanly, you can decommission with confidence.

Step 4: Connect the destination platform immediately

As soon as the migration is complete and you've verified the initial data, connect the destination platform to your backup tool.

Migration day is not the time to start thinking about backup coverage on the new platform. The early days after a migration are actually the highest-risk period for data loss: the team is still adapting, workflows are being rebuilt, and small configuration mistakes are common. Your effective RPO on the new platform is undefined until you have at least one snapshot running. If someone accidentally deletes a project they thought was a test project but was actually a real one, you want that covered from day one.

In ProBackup, connecting the destination platform takes about three minutes. The first backup snapshot will run within 24 hours. From that point, you have continuous coverage on the new platform with the same retention and restore capabilities as your old one.

Using your backup data during a migration

Even if you use a dedicated migration tool (which you should, for the actual data transfer), your ProBackup backup data is useful as a reference during the migration process.

As a verification source. Export your source platform data from the backup vault as Excel files. Use these as your ground truth when checking that migration data landed correctly. The vault export includes field configurations and data types that a raw CSV might not preserve, so it's a more reliable comparison document than a native platform export.

For accessing attachments. If you need to retrieve specific files from the source platform after the migration, ProBackup's attachment download feature lets you download individual files or, on Premium, bulk download all attachments for a project as a ZIP file. This is particularly useful if the migration tool didn't copy attachments and you need to manually upload them to the new platform.

For rollback scenarios. If the migration corrupts data and you need to restore the source platform to a working state, ProBackup can restore data to the original platform instance. This gives you a clean rollback path if the migration has to be aborted and restarted.

As a read-only archive. After the migration is complete and the source account is cancelled, the backup vault remains accessible. Teams who need to reference historical data from the old platform (for client work, compliance, or institutional knowledge) can browse and export it from the vault indefinitely, within their retention period.

What ProBackup doesn't do in a migration

Being clear about this matters, because it's easy to conflate backup with migration and end up with gaps.

ProBackup is not a migration tool. It can't move your data from Trello to Asana, or from monday.com to ClickUp. It doesn't map fields between platforms, handle schema transformations, or write data to a different platform than the one it backed up. For the actual data transfer, you need a dedicated migration tool (Truvault, Orca, AppVizer, or the native import features on the destination platform, depending on which platforms you're moving between).

What ProBackup provides in a migration context is the safety net: a complete, independent, searchable snapshot of your data before the migration starts, continuous coverage during the transition period, a verification reference during the migration, and a rollback path if something goes wrong.

The migration tool moves your data. ProBackup protects it.

What to do next

A platform migration usually means the team has outgrown something, which means the data you're moving matters more than it did when you first started using the platform. It's worth protecting properly.

If you have a migration coming up, start by connecting your source platform to ProBackup now, before any migration activity begins. Plans start at $25/month (billed yearly) and include all supported platforms under a single licence: Asana, monday.com, ClickUp, Trello, HubSpot, Notion, Jira, Airtable, Slack, and more.

Once the migration is complete, connect the destination platform to the same account. Your backup history on the source platform stays accessible, and coverage on the new platform starts immediately.

If you want to understand the broader data protection strategy for your SaaS stack, the SaaS data protection audit post walks through how to inventory your apps and identify gaps. The backup policy template includes a scope table that's worth updating to reflect any new platforms after a migration.

See how other teams use ProBackup to protect business-critical data on our success stories page.

‍

In short: Audit your SaaS stack in five steps: inventory every app (identity provider, expense reports, OAuth grants), tier each by data criticality, document each app's native recovery (most trash bins cap at 30 days, Trello has none for cards, HubSpot gives 90), compare that against your RTO and RPO, then assign a protection plan per app. A free worksheet is included.

You probably know what SaaS apps your team uses. You probably don't know which of them are actually protected.

That's not a criticism. It's just how SaaS adoption works. Someone signs up for Notion to manage a knowledge base. Another team starts using Airtable for client tracking. HubSpot gets connected to three different integrations. Each tool is evaluated for features and price, and almost never for what happens when data inside it disappears.

The result is a SaaS stack where some apps are backed up, some aren't, and nobody has a complete picture of where the gaps are. The shared responsibility model means your providers aren't filling those gaps for you. They protect the platform. You protect the data.

This post walks through a five-step audit process to find your gaps and fix them. It shouldn't take more than an afternoon, and you'll come out of it with a clear map of what's protected, what isn't, and what to do about it.

Why you need a SaaS data protection audit

Most teams discover their data protection gaps after an incident. Someone deletes a board. An import corrupts 200 records. A former employee's private workspace turns out to have never been included in the backup scope.

The audit prevents that. It forces you to answer, for every app in your stack: what happens if we lose this data tomorrow? And the honest answer, more often than not, is "we don't know."

There are also compliance reasons. If you're pursuing or maintaining SOC 2, ISO 27001, or GDPR compliance, auditors will expect you to demonstrate that you've identified the systems containing critical data and have documented protection measures for each one. An ad hoc backup setup connected to three out of nine apps won't pass that review.

But the simplest reason is this: your SaaS stack has probably grown since anyone last thought about data protection. The average team adds two or three new tools per year. Each one is a potential gap if nobody stops to ask whether it's covered.

Step 1: Inventory every SaaS app your team uses

Start with a full list. Not just the apps you pay for. Every SaaS tool that contains data someone on your team would miss if it vanished.

Check your identity provider (Okta, Google Workspace, Azure AD) for a list of connected applications. Check expense reports and credit card statements for SaaS subscriptions. Check browser extensions and OAuth permissions. Ask department leads what tools their teams use day-to-day.

You'll find apps you forgot about. You'll find apps you didn't know the team was using. That's normal. The average mid-size company uses somewhere between 50 and 100 SaaS apps, and IT typically knows about 60-70% of them.

For each app, record:

• The app name and what it's used for
• Which team or department owns it
• How many users have access
• Whether it's paid or on a free tier (free tiers often have weaker retention and recovery)
• Whether it's connected to other apps via integrations or APIs

Don't filter at this stage. The goal is a complete inventory. You'll prioritise in the next step.

Step 2: Map which apps hold business-critical data

Not every SaaS app needs the same level of protection. The tool your design team uses to brainstorm mood boards is different from the CRM that holds every client interaction for the past three years.

Go through your inventory and categorise each app by data criticality:

Tier 1: Business-critical. Losing this data would directly impact revenue, client relationships, compliance, or operations. Think CRM data (HubSpot, Salesforce), project management (Asana, monday.com, ClickUp, Jira), client-facing knowledge bases, financial records, and any app where data loss means work has to be reconstructed from scratch.

Tier 2: Important but recoverable. Losing this data would be painful and time-consuming, but the business could reconstruct it within a reasonable timeframe. Internal wikis, communication archives (Slack), design assets, and secondary project tools often fall here.

Tier 3: Low impact. Losing this data would be an inconvenience, not a crisis. Tools used for brainstorming, non-critical scheduling, or internal experimentation.

Your Tier 1 apps are the priority. Everything else can follow, but if your CRM and project management tools aren't protected, you have a problem regardless of what's happening with the rest.

Step 3: Check native backup and recovery options

For each Tier 1 and Tier 2 app, document what the platform itself offers for data recovery. This is where most teams discover their assumptions don't match reality.

Look up three things:

Recycle bin / trash retention. How long do deleted items stay recoverable? Most platforms cap at 30 days. Trello has no recycle bin for cards at all. HubSpot gives you 90 days for records but only 30 for files.

Version history. Can you roll back individual records to a previous state? Notion offers version history but it's limited to 7 days on the Free plan and 30 on Plus. Most project management tools don't version-control field configurations or custom field values at all.

Export options. Can you export your data manually? In what format? How complete is the export? Many platforms offer CSV exports that miss comments, file attachments, field history, and relational data. An export that gives you task names without their comments, assignees, and custom fields isn't really a backup.

For each app, record the answers in a simple table. You'll quickly see a pattern: most native recovery features are designed for "I accidentally deleted this five minutes ago," not for "something went wrong three weeks ago and we just noticed."

Step 4: Identify gaps in retention and restore

Now compare what each app offers against what you actually need. This is where the audit gets useful.

For each Tier 1 app, ask:

Is 30 days of recycle bin retention enough? If your team wouldn't notice a data problem within 30 days (and for slow-burn issues like integration corruption or field-level overwrites, they often wouldn't), then the native retention window is too short.

Does the recycle bin cover the right data types? Most recycle bins only cover top-level items like tasks and projects. Changes to field configurations, custom field values, automations, and views are typically not recoverable from trash.

What about bulk overwrites and integration errors? A bad CSV import that changes 500 field values doesn't trigger a trash event. Neither does a misbehaving integration. These are among the most common data loss scenarios, and no native recycle bin catches them.

What's your actual RTO and RPO? If you've already defined your Recovery Time Objective and Recovery Point Objective, check whether your current protection can meet them. If your RPO is 24 hours but your only recovery option is a manual CSV export from last quarter, you're not meeting it.

Are access controls adequate? Can a single user permanently delete data from the recycle bin? Is MFA enforced? Who has admin access that doesn't need it? These aren't backup questions per se, but they're data protection gaps the audit should surface.

Document each gap. Be specific: "monday.com: 30-day recycle bin doesn't cover field configuration changes. No protection against bulk import errors. RPO effectively undefined."

Step 5: Build a protection plan for each app

For every gap you've identified, decide how to close it. There are really only three options:

Accept the risk. For Tier 3 apps, this might be fine. If losing the data would be a minor inconvenience and the cost of protecting it isn't justified, document the decision and move on. The key is making it a conscious choice, not an oversight.

Implement manual workarounds. Scheduled CSV exports, manual screenshots of dashboards, periodic data exports to Google Drive. These work for low-volume apps with simple data structures. They don't scale, they're error-prone, and they depend on someone remembering to do them. But for an app with five users and limited data, they might be enough.

Set up automated independent backups. For Tier 1 and most Tier 2 apps, this is the answer. You need a backup tool that runs automatically, stores data independently from the source platform, and lets you restore to a specific point in time.

ProBackup covers 20+ platforms under a single licence, including Asana, monday.com, ClickUp, Trello, Notion, HubSpot, Jira, Airtable, Slack, and more. Daily automated snapshots stored in AWS with AES-256 encryption, in one of nine AWS regions selected by the customer at signup, with that region applying to every backup in the ProBackup account. Granular restore down to individual records, comments, and files. Retention of 6 months on Plus, 2 years on Pro, and unlimited on Premium. Plans start at $25/month (billed yearly).

If you're also building or updating a formal backup policy as part of this audit, our post on how to build a SaaS backup policy includes a downloadable template.

Free template: SaaS data protection audit worksheet

We've created a spreadsheet template to make this audit easier. It includes:

• An app inventory tab with columns for name, department, user count, tier, and integration dependencies
• A native recovery tab to document each app's recycle bin retention, version history, and export options
• A gap analysis tab that maps each gap to a remediation action (accept, manual workaround, or automated backup)
• A protection plan summary with backup tool, frequency, retention, and owner per app

Download the audit worksheet →

The worksheet follows the same five-step process described in this post. Fill it in with your team, and you'll have a complete picture of your SaaS data protection posture in an afternoon.

What to do next

Run the audit. It doesn't need to be perfect on the first pass. Start with your Tier 1 apps, document what you find, and address the gaps. You can expand to Tier 2 and Tier 3 apps over the following weeks.

If the audit reveals that most of your critical SaaS data isn't independently backed up (and for most teams, it will), start a free trial of ProBackup. Setup takes about three minutes per app. Your first snapshot runs within 24 hours. See how other teams have used ProBackup to close their data protection gaps on our success stories page. And if you're running this audit as the person responsible for your company's tooling, our ProBackup for IT admins page covers how to manage backups across your whole organisation.

‍

In short: SaaS recycle bins are not backups. They only hold deleted items, for a limited window — typically 30 days, 90 on HubSpot, none at all for Trello cards — and they miss data that was overwritten by edits, imports or integrations. Reliable protection requires an independent backup that snapshots your workspace daily and can restore any item to a chosen date.

Your SaaS app has a recycle bin. You've seen it. Maybe you've even used it once or twice to fish out a task someone deleted by accident. It worked, and you moved on with your day.

That experience is exactly what makes recycle bins dangerous. They work just often enough that you start to trust them as a safety net. They're not. They're a convenience feature with a countdown timer, and when you actually need them, in a real data loss scenario, they will let you down in ways you didn't expect.

The story usually goes something like: "I assumed the recycle bin would have it." It didn't. The item had expired, or it was the wrong data type, or someone had emptied the bin, or the deletion happened through an integration that bypassed the bin entirely. The shared responsibility model means your SaaS provider keeps the platform running. Protecting your data is on you.

This post breaks down what recycle bins actually do, where they fall short, and what you need instead.

What SaaS recycle bins actually do

Before we get into the problems, it's worth understanding what these features are designed for. Most SaaS apps handle deletion in two or three stages, and the terminology isn't consistent across platforms.

Archive/close is a soft delete. The item is hidden from active views but still exists in your workspace. You can usually bring it back at any time. Trello calls this "Archive." ClickUp calls it "Close." The item is still there, just tucked away.

Recycle bin/trash is a time-limited holding area. Deleted items sit here for a fixed number of days before they're permanently removed. This is what most people think of as "undo." Asana, monday.com, ClickUp, Notion, and HubSpot all have some version of this.

Permanent delete is exactly what it sounds like. Gone. No recovery path through the platform, no support ticket that will bring it back. Some platforms let users jump straight to this step. Trello, notably, sends deleted cards straight to permanent deletion with no recycle bin in between.

The recycle bin stage is the one teams rely on. And for simple, recent, single-item deletions? It genuinely works. The problem is that data loss rarely looks like that.

How retention works across popular platforms

The details matter here, because each platform handles recovery differently. Here's what the retention policies actually look like in practice.

Asana: Deleted items are searchable for 30 days via Advanced Search with the "Deleted" filter. There's no visual recycle bin in the interface. After 30 days, items are permanently removed. Projects, tasks, and subtasks are all covered, but once deleted, attachments and comments on those items are harder to recover separately.

monday.com: The Recycle Bin retains deleted items for 30 days. Workspace owners and admins can view and restore items deleted by any user. After 30 days, data is permanently purged. Subitems are included in board-level deletions, but restoring a board doesn't always restore its subitems cleanly.

ClickUp: Trash retains deleted items for 30 days. Members and guests can only see items they personally deleted, while admins and owners see everything. Comments and certain views cannot be restored from Trash, even within the 30-day window. Also: if a Folder or List is deleted, individual tasks within it don't appear separately in the Trash. You have to restore the whole container to get them back.

Notion: Trash retains deleted pages for 30 days by default. Enterprise plans can customise this to up to 10 years. Version history is available for 7 days on the Free plan, 30 days on Plus, and 90 days on Business. So even if a page is in your Trash, the version you actually need might already be gone from history. Worth reading alongside Notion AI and your data if your team uses those features.

HubSpot: The most generous of the group. Records (contacts, deals, companies, tickets) stay in the recycle bin for 90 days. Files, however, only stay for 30 days. And GDPR-related permanent deletions bypass the recycle bin entirely. Records permanently deleted for compliance reasons are immediately and irreversibly gone.

Trello: The outlier. Trello has no recycle bin at all for cards. If you hit "Delete" on a card (rather than "Archive"), it is permanently removed. Trello support cannot recover deleted cards. This catches a lot of teams off guard, especially those coming from platforms with a proper trash folder.

Slack: There is no trash for deleted messages, which is why teams back up Slack channels separately.

Podio: No recycle bin either, and Podio's documentation states that deleted items and apps cannot be recovered, which is why a Podio backup has to sit outside the platform.

Five ways recycle bins fail you

The 30-day window (or 90 for HubSpot) sounds reasonable in theory. In practice, these are the scenarios where it breaks down.

1. The slow discovery problem

Not all data loss is obvious. Someone deletes a project or modifies a field, and nobody notices for six weeks. By the time someone asks "where did that go?", the recycle bin expired five weeks ago. This is especially common with data that's referenced infrequently, like archived client records, completed project boards, or historical reporting data. The longer it takes to notice, the less likely your recycle bin will help.

2. Selective coverage

Recycle bins don't protect everything. Across most platforms, automations, views, forms, and field configurations are not recoverable from trash. In ClickUp, comments deleted from a task are permanently gone, no Trash entry. In Trello, Power-Ups and automations aren't backed up via the API at all, and they're not covered by the archive system either. The gaps vary by platform, but every platform has them.

3. Bulk operations can bypass them

A bad CSV import that overwrites 2,000 records doesn't delete anything. It updates existing records with wrong values. No recycle bin in any SaaS app will catch that, because from the platform's perspective, no deletion occurred. Similarly, a misbehaving third-party integration that clears field values or reassigns tasks in bulk won't trigger a trash event. These are among the most common data loss scenarios we encounter, and the recycle bin is completely blind to them.

4. Malicious deletion can empty them

In most SaaS apps, anyone with admin access (or even regular member access in some cases) can permanently delete items from the Trash before the retention period expires. A disgruntled employee who wants to cause damage won't just delete your project, they'll empty the trash too. ClickUp and monday.com both allow admins to permanently delete items from Trash. HubSpot allows GDPR-style permanent deletion that bypasses the recycle bin entirely. If someone has the intent and the access, the recycle bin won't stop them. An independent backup can at least get you alerted when records are deleted.

5. No compliance trail

Recycle bins don't give you point-in-time recovery. They can't show you what your data looked like on a specific date three months ago. They don't provide audit trails of who deleted what and when (beyond basic activity logs). If you're subject to GDPR data retention requirements, SOC 2 controls, or just need to prove the state of a project at a specific point in time for a client dispute, recycle bins give you nothing to work with.

The gap between "undo" and "backup"

There's a useful way to think about this. A recycle bin is an undo button. A backup is an insurance policy.

An undo button is great for "I just deleted that by accident, let me grab it back." It's immediate, it's simple, and it works for recent, obvious mistakes.

An insurance policy covers you when things go genuinely wrong. When the damage isn't obvious for weeks. When the problem is data corruption, not deletion. When someone acts maliciously. When you need to prove what your data looked like at a specific point in time.

These are different tools for different problems. The mistake most teams make is treating the undo button as if it were an insurance policy. It isn't. And the shared responsibility model your SaaS provider operates under makes it clear that actual data protection is your job.

What a real backup gives you that recycle bins don't

We're obviously biased here, but we'll be specific about what we do and what we don't do.

ProBackup runs daily automated snapshots of your SaaS data. Every 24 hours, we capture a complete copy of your workspace, including tasks, items, records, comments, attachments and other metadata, custom field values, and field configurations. That snapshot is stored in our own AWS infrastructure, in one of nine AWS regions — you select the region at signup and it applies to every backup in your ProBackup account — encrypted with AES-256, using authentication tokens that are completely separate from your SaaS accounts.

That separation is the critical difference. If your SaaS account is compromised, your backups are untouched. If someone empties the recycle bin, your snapshots are still there. If an import corrupts 500 records and nobody notices for two months, you can go back to the snapshot from the day before the import and restore exactly what you need.

What we can restore: individual tasks, records, cards, comments, files, custom field values, and entire projects or boards. You pick the date, select the items, and click restore. The platform creates a new copy, so nothing gets overwritten.

What we can't back up (because the APIs don't expose them): automations, forms, and dashboard configurations on most platforms. Trello Power-Ups and views. Files uploaded directly to items in monday.com (as opposed to via custom fields). We're transparent about these limits because they're real, and we don't want anyone surprised. The full list for each platform is in our Help Centre.

On the Pro and Premium plans, we also run smart alerts that notify you when unusual deletion activity is detected. So if someone deletes 50 tasks in a single hour, you'll know before the recycle bin even becomes relevant.

We support 20+ platforms under a single licence, including Asana, monday.com, ClickUp, Trello, Notion, HubSpot, Jira, Airtable, and Slack. Plans start at $25/month (billed yearly). See how other teams have recovered from data loss on our success stories page.

What to do next

Check your SaaS apps' recycle bin policies. Look up the retention period, what data types are covered, and who can permanently delete from Trash. If your answer to "what happens when the recycle bin isn't enough?" is "I don't know," you have a gap.

The ultimate SaaS backup and recovery guide walks through how to build a proper backup strategy. Or if you'd rather just see it working, start a free trial. Setup takes about three minutes, and your first snapshot runs within 24 hours.

In short: The AI features in HubSpot, Asana, ClickUp and monday.com no longer just draft text; they create and update records on their own triggers. A bad run is a bulk edit at machine speed. Contain it with scoped permissions, approval steps and deletion alerts, and keep an independent daily snapshot to roll the affected records back field by field.

What changed in 2025–26

Two years ago, "AI in your project tool" meant a summarise button. Today the same platforms ship agents that act on your data without a human clicking each step. From the vendors' own documentation, checked 2026-09-16:

• HubSpot Breeze. HubSpot's Breeze Assistant can "create new records or update existing ones, including properties, owners, and associations, for all CRM objects" and can "create tickets, update ticket properties, change statuses, and assign owners" (HubSpot Knowledge Base). The Breeze agents launched in spring 2025 include a Customer Agent that "takes action" on support tickets and a Prospecting Agent that engages prospects "in your Smart CRM" (HubSpot).
• Asana AI Studio. Teams write "plain-language instructions for what AI should do"; the workflows can "move work into the right projects automatically", "direct work to the right team, owner, or approval stage" and "trigger actions and sync data across your connected tools" (Asana).
• ClickUp Autopilot Agents. They "perform actions based on defined triggers and conditions" and "adapt to changes in your Workspace to autonomously act based on the instructions given", running on Lists, Folders, Spaces and Chat channels (ClickUp Help, Create and configure Autopilot Agents). The help centre also lists task creation and Custom Field updates among the available agent tools.
• monday.com AI blocks. AI-powered column actions use monday AI blocks to "analyze, summarize, and generate content directly within your boards" (monday.com support); the API reference confirms each AI-column mutation writes its result into the configured column (monday.com developer docs). monday.com's agent builder lets you define "whether it has permission to edit, create, or only read" (monday.com).

The common thread: these features write to the same tasks, deals, items and tickets your team works in, under whatever permission the configuring user or connected account holds.

The cost of getting it wrong is no longer theoretical. In July 2025 the founder of SaaStr reported that Replit's AI agent deleted his production database despite explicit instructions not to change anything during a code freeze; Replit acknowledged "a catastrophic error of judgement" and initially told him a rollback was impossible, which turned out to be wrong (The Register, 21 July 2025, checked 2026-09-16). In April 2026 the founder of PocketOS, a car-rental SaaS, reported that a Cursor coding agent "deleted our production database and all volume-level backups in a single API call" to its cloud provider, in nine seconds, after finding a broadly scoped API token and guessing at the scope of a delete (Tom's Hardware, 27 April 2026; XDA Developers, 28 April 2026, checked 2026-09-16).

Both were coding agents acting on databases. The mechanics translate directly to a business agent acting on a CRM or a project board: broad credentials, an ambiguous instruction, no approval step, and the backup sitting inside the same blast radius.

The three failure modes

Agent incidents in SaaS tools fall into three shapes. Naming them helps because the containment and the rollback differ for each.

1. Bulk overwrite

The agent updates a field across many records with a wrong value: every open deal moved to "Closed lost", every task reassigned to one person, a priority column rewritten by a prompt that misread the context. Nothing is deleted, so nothing lands in a trash folder and no "record deleted" alert fires. The records look normal; the data inside them is wrong.

2. Mass delete

The agent removes records, or archives or closes them in a way that hides them from working views. Native trash windows vary by platform and plan (see our platform-by-platform guide to restricting deletions); some platforms have no trash at all for certain objects. Past the window, the records are gone from the vendor's side.

3. Cascade via automations

The agent's write is correct in isolation but trips existing automations: a status change that fires a "notify customer" email, a stage change that triggers a downstream sync, a field update that another agent reacts to. One action becomes hundreds, across several tools, before anyone sees the first one.

The third mode is the one teams under-plan for, because each rule was sensible when a human was the only thing pressing the trigger.

Containment: reduce the blast radius before the first run

None of this is a reason to switch the agents off. It is a reason to run them with the same discipline you would apply to a new integration with write access.

Least-privilege service accounts. Run the agent under its own user or service account with the minimum role it needs, not under an admin's identity. If the platform lets you restrict the agent to specific projects, boards, pipelines or Spaces, do it. monday.com's agent builder, for example, lets you define "exactly which data the agent can access" and whether it may "edit, create, or only read" (monday.com, checked 2026-09-16).

Scoped OAuth for external agents. An agent that connects through an API or MCP integration holds an OAuth token or API key. Grant only the scopes it needs, prefer read scopes until the write behaviour is proven, and rotate or revoke the credential when the pilot ends. The PocketOS incident began with a token that granted far more than the task needed.

Dry-run and approval steps. Where the platform offers a simulation, planning or draft mode, use it for the first weeks and review what the agent would have done. Where it does not, route writes through a human-approval step (an "AI proposed" status, a review column, a draft ticket) rather than letting the agent commit directly. Start with a small scope, one project or one pipeline, and widen it after a review.

Deletion alerts. Make a bulk deletion or bulk change visible within a day, not a quarter. ProBackup's Smart Alerts (Pro and Premium plans) flag unusual deletions in the daily report so you can act while the snapshot from the day before is one click away. See proactive alerts and weekly reports.

Keep the automation map current. List which automations fire on which field or status changes, per tool. If an agent can change that field, it can trigger that automation. Pause or add conditions to the ones that send external messages or push to other systems.

Rollback: undo the bad run from a snapshot

Containment reduces how often you need a rollback and how far it reaches. A snapshot is what makes the rollback possible at all, and it needs to sit outside the agent's reach.

ProBackup is a SaaS backup service that takes automated daily snapshots of your cloud app data and lets you restore individual records, files or whole projects back to the original account. Snapshots are stored on AWS S3 in your chosen region, independent of the platform's own trash and version history, and the agent has no credential to it.

Two restore modes map onto the failure modes above:

• Restore as new records recreates deleted records from any snapshot as duplicates in their original location. The safe default for a mass delete: nothing currently live is touched.
• Overwrite existing records writes values from a previous snapshot back into the live record, and you choose the fields. This is the fix for a bulk overwrite: pick the snapshot from before the run, select the affected records, tick only the fields the agent changed, and everything else, including edits your team made since, stays as it is.

Overwrite mode is available for HubSpot, ClickUp, Asana, monday.com, Airtable and Attio. Calculated fields (system fields, formulas, relations) are excluded because the platforms compute them; ProBackup shows these constraints in the restore pane before you confirm. There is no per-restore record limit. The full walkthrough is in overwrite existing records when restoring data, and the feature overview in granular restore.

A practical rollback sequence:

1. Stop the agent. Disable the automation or revoke its token first, so you are not restoring into a moving target.
2. Find the last good snapshot. Snapshots are daily; pick the one dated before the run started. Global Search (unlimited on Pro and Premium; 3 free uses per month on Plus) finds a record across snapshots when you only remember a name.
3. Restore deleted records as new. For a mass delete, restore the affected collection or the individual records as duplicates.
4. Overwrite changed fields. For a bulk overwrite, use overwrite mode with the field picker on the affected records.
5. Check the cascade. Look at the other tools the automations touched and repeat the same steps there; ProBackup covers 20+ platforms from one account, so the snapshots for the downstream tool are already there.

For a step-by-step on the overwrite case, see how to roll back a bulk edit in your SaaS apps.

Agent-safe checklist

Five items, in the order a team should do them:

1. Snapshot first. Connect the platform to ProBackup and confirm the first snapshot completed before the agent gets write access. A rollback needs a "before".
2. Own identity, minimum scope. The agent runs as its own user or token, with read-only scopes until its writes are reviewed, and is limited to the projects, pipelines or boards it serves.
3. Approval on writes. Agent output lands in a draft state or review column; a person promotes it. Widen the scope only after a review of what it did.
4. Alerts on deletions and bulk changes. Smart Alerts (Pro and Premium plans) on, weekly report read by a named owner, and a rule for who decides on a restore.
5. Test the rollback once. Restore one record as a duplicate and overwrite one field on a test record, so the first real rollback is not also the first rehearsal. Repeat quarterly.

Frequently asked questions

Can an AI agent in HubSpot or Asana really change my data without a person approving each step?

Yes. HubSpot documents that Breeze Assistant can create and update records, properties, owners and associations for all CRM objects; Asana AI Studio workflows move work between projects and route it to owners based on plain-language instructions (sources above, checked 2026-09-16). Whether a person approves each step depends on how you configure the workflow, which is why approval steps are in the checklist.

If the agent overwrote fields rather than deleting records, can I still roll back?

Yes, with overwrite mode: select the records, pick a snapshot from before the run and choose only the fields to restore. Available for HubSpot, ClickUp, Asana, monday.com, Airtable and Attio; calculated fields are excluded.

Does the platform's own version history cover this?

Sometimes, for a handful of records. Version history and trash windows differ by platform and plan, and a bulk change of hundreds of records is impractical to unwind one at a time. An independent snapshot gives you a single point in time to restore from, across the whole collection.

How quickly can I detect a bad run?

ProBackup takes a snapshot every 24 hours and Smart Alerts (Pro and Premium plans) flag unusual deletions in the daily report. Detection inside the day depends on the platform's own notifications and on the approval steps you configure; the snapshot is what guarantees you can undo it once you know.

Back up before you switch the agent on

Connect HubSpot, Asana, ClickUp or monday.com to ProBackup in a few minutes via OAuth. Snapshots run every 24 hours, encrypted with AES-256 at rest and TLS in transit, and ProBackup is SOC 2 Type II certified (May 2025). Plans start at $25 per month, billed yearly.

Start your free 7-day trial, no credit card required. Platform pages: HubSpot, Asana, ClickUp, monday.com.

In short: Syncing ProBackup backups to Google Drive (Pro and Premium plans) gives you an independent copy outside ProBackup, records as Google Sheets that colleagues can read without a ProBackup login, one-click bulk download of a whole backup history including attachments, and, with Google Drive for Desktop, an automatic local copy for the 3-2-1 rule. Apps over 50,000 records get no Sheet.

At ProBackup, our primary mission is to provide you with peace of mind. When we back up your SaaS apps. whether it’s Asana, Monday, or ClickUp, we utilize heavy encryption to store that data securely on our own servers . This automated, daily process is the foundation we rely on when you need to restore a specific record or an entire project back to your account.

However, we believe in robust data resilience. That is why we offer our users the option to sync a copy of their data backups directly to their own Google Drive. While this feature is optional (available on our Pro and Premium plans ), we strongly recommend it.

Why add this extra step? Here are four reasons why syncing to Google Drive elevates your data security strategy.

1. An extra layer of redundancy

In the world of data protection, redundancy is key. While ProBackup maintains a rigorous uptime schedule to protect you against glitches, human error, or malicious intent, true "cloud resilience" means never relying on a single point of failure — the idea behind the 3-2-1 backup rule.

By syncing to Google Drive, you create an independent fallback. In the unlikely event that our service is temporarily unavailable, you retain immediate access to your data through your own Google infrastructure. This ensures that you are never cut off from your vital business information, regardless of the status of your SaaS provider or your backup service. It also avoids a classic mistake: backing up to the same provider that holds your live data.

2. Instant accessibility in a familiar format

While the ProBackup app provides an easy way to navigate and search your data backups, you might prefer a more familiar workflow.

Syncing your data to Google Drive converts your records into Google Sheets. This provides a major advantage: familiarity. Unlike obscure file formats like CSV or JSON, Google Sheets are easy to read, share, and analyze. This allows stakeholders who may not have access to the ProBackup dashboard to review archived data in a format they already use every day .

3. Bulk downloading made easy

Need to get your data out of the cloud entirely? Within the ProBackup app interface, downloading every single data table across your account simultaneously isn't always feasible. Google Drive solves this.

When your data is synced to Google Drive, your entire backup history is organized into folders. With just a few clicks, you can select the parent folder and download it as a Zip file.

• Pro Tip: If you enable the sync of files and attachments , this method allows you to bulk download every document and image attached to your tasks in one go—saving you hours of manual clicking.

4. Automated local backups via Drive for Desktop

The "3-2-1 backup rule" suggests keeping at least one copy of your data off-site/locally. You can automate this workflow by combining ProBackup with the "Google Drive for Desktop" application.

Once installed, Drive for Desktop syncs your cloud folders to your local hard drive. This creates a seamless chain of data flow:

1. ProBackup captures data from your SaaS app.
2. ProBackup syncs that data to your Google Cloud.
3. Drive for Desktop pulls that data down to your local computer.

This setup ensures that even if you lose internet access entirely, you have a local, searchable copy of your business data waiting for you. Drive sync is a Pro and Premium feature, so compare ProBackup plans to see which one fits.

In short: The five most common SaaS data loss scenarios are human error (deleting a whole project instead of one task), malicious insiders, platform glitches and downtime, faulty imports or third-party integrations that overwrite records, and ransomware entering through one compromised login. SaaS providers recover their own infrastructure, not your account data, so an independent daily backup is the defence.

While most SaaS (Software as a Service) providers have robust disaster recovery plans for their platforms, they don't typically take responsibility for data loss within your individual account. This means that if critical information is lost due to an issue on your end, you are ultimately responsible for its recovery.

Using SaaS applications to manage your work introduces certain risks, and losing key data can happen in several ways. Here are four major threats you should protect your team against.

1. Human Error

This is the number one reason for data loss. It's surprisingly easy for a team member to make a mistake that can set you back hours or even days. In many productivity apps, it only takes a few clicks to delete an entire project or board. A user might intend to delete a single task but accidentally have the whole table selected, or they might choose the "delete" option instead of "archive."

It's also common to need to roll back smaller mistakes, like accidentally changing a field configuration, removing a value from a selection field, or overwriting the wrong column with a data import. While some of these minor issues can be undone within the app itself, others require a dedicated backup and restore tool to revert the changes.

2. Malicious Users

Internal threats can be just as damaging as external ones. In many companies, authorization controls can be relaxed, allowing most team members to make significant updates or even delete crucial data. A disgruntled employee could intentionally delete entire projects or boards to harm the company.

There are also less severe but still problematic cases where lazy team members might delete data to lighten their workload, such as removing sales leads to avoid follow-ups or deleting tasks to hide a missed deadline. When work is managed in a shared online space, an independent backup ensures you have a true record of all activity.

3. Glitches & Down-time

Most major SaaS apps have a strong record for uptime, but no service is perfect. Even minor glitches, bugs from third-party integrations, or temporary down-time can significantly impact your business operations.

Imagine not being able to access prep work right before a client meeting or look up contract details during a call. An independent, third-party backup of your data ensures you have 24/7 access to your essential business information, even when the primary service is unavailable.

4. Faulty Data Imports & Third-Party Integrations

Integrating other applications or importing data from spreadsheets is a common way to streamline workflows, but these operations can be deceptively risky. A simple misstep, like a bad field mapping or importing a file with the wrong format, can instantly compromise your data's integrity.

5. Ransomware

Many people assume ransomware only targets large corporations, but in reality, hackers often go after smaller businesses, which may lack stringent security controls. By gaining access through a single employee's credentials, attackers can hold your data hostage and demand a hefty ransom. An effective backup strategy is your best defense, allowing you to restore your data and continue operations without paying the attackers.

Smaller companies are often hit hardest by all five of these scenarios. See how ProBackup helps founders protect their business data from day one.

In short: Before storing business-critical data in a SaaS app, check nine things: admin-enforced two-factor authentication, past security incidents and how they were handled, uptime record and SLA, a trash bin or archive with a stated retention window, deletion alerts for admins, role-based control over who can delete, native backups or exports, support for third-party backup services, and Zapier or Make.com integrations.

Choosing the right SaaS app to store your business data is a big decision. If an app isn’t secure, your data could be stolen, lost, or accidentally deleted. A security breach could cost your business money, time, and trust. So, how can you tell if a SaaS app is safe to use? Here’s a checklist to help you decide before you commit to a new app.

Can the Admin Make Everyone Use Two-Factor Authentication (2FA)?

Two-Factor Authentication (2FA) adds an extra layer of protection, making it much harder for hackers to access accounts. A good SaaS app should allow admins to enforce 2FA for all users. If it’s optional, some users might skip it, leaving your business at risk.

With 2FA, even if a password gets stolen, hackers still need a second factor, like a mobile code or biometric confirmation to access an account. Apps that offer 2FA but don’t enforce it leave a major security hole. Always check if admin enforcement is available and ensure your team follows the policy.

Has the App Had Security Problems in the Past?

Before trusting an app, check if it has had any security breaches. Search online for reports of past hacks or data leaks. You can also check the company’s security page or transparency reports. If the app has had issues but handled them well and improved its security, that’s a good sign. However, if it has a history of repeated problems, you might want to look for a more secure alternative. 

Look at how the company responds to incidents. Do they have a history of taking quick action, notifying users, and strengthening security? A provider that learns from past breaches and actively invests in security improvements is far better than one that tries to cover up issues or ignores them. Ask for independent assurance as well: with ProBackup you can request the SOC 2 Type II report. 

Does the App Have a Good Uptime Record?

Uptime refers to how often the app is working without outages. Frequent downtime can indicate security issues or poor infrastructure. Many SaaS apps have a status page where you can check their uptime history. If an app goes down often, it might not be reliable enough for business-critical data. 

Downtime doesn’t just mean inconvenience. It could indicate underlying security issues, such as DDoS attacks or poor server management. Check the provider’s history of downtime incidents, read user reviews, and ensure they offer a service level agreement (SLA) with uptime guarantees. 

Does the App Have a Trash Bin or Archive System?

People make mistakes, and sometimes important files get deleted by accident. A secure SaaS app should have a trash bin or archive feature that lets you restore deleted data. Make sure to check how long deleted data is stored before it’s permanently erased. 

Some apps keep deleted data for only a few days, while others offer extended retention periods. Ideally, the app should have flexible options where admins can set retention policies to match business needs. If an app permanently deletes data with no way to recover it, you could be at risk of losing crucial information. 

Does the Admin Get Alerts When Data is Deleted?

Admins should be notified when important data is deleted. A good SaaS app will send alerts when someone removes files or records, allowing you to catch accidental or unauthorized deletions before they cause problems.

These alerts should include details like who deleted the data, when it happened, and whether it can be recovered. Some apps even allow admins to review and approve deletions before they take effect. If an app lacks these features, it may be harder to track and prevent data loss.

Can You Control Who Can Delete Data?

Not every team member should have permission to delete data. A strong SaaS app will let you assign different roles and permissions so that only certain users can make changes. This prevents accidental deletions and limits the risk of internal security threats. 

Role-based access control (RBAC) is essential for managing user permissions. The best apps allow detailed customization so that sensitive data is only accessible to those who need it. If an app doesn’t offer this, consider whether it’s secure enough for your business.

Does the App Have Backups, Snapshots, or Export Options?

Even the best systems fail sometimes. A secure SaaS app should have automatic backups, snapshots, or export features that let you recover old versions of your data. If an app doesn’t offer these options, losing data could be permanent.

Find out how often backups are made, where they are stored, and how easy it is to restore them. Some apps only back up data once a day, while others offer continuous backup. The more frequent and accessible the backups, the safer your data will be. Where the vendor’s duty ends and yours begins is set out in the shared responsibility model.

Can the App Work with Backup Services Like ProBackup or SysCloud?

Relying solely on the app’s internal backup system can be risky. Third-party backup services like ProBackup offer extra protection by automatically saving copies of your data. This ensures that even if the app itself fails, you still have a backup to restore your information. It is worth reading how ProBackup secures backup data before you connect an app.

Using an external backup service adds an extra layer of protection. It prevents data loss due to software errors, cyberattacks, or human mistakes. If a SaaS app doesn’t integrate with third-party backup providers, you may need to rely on manual exports, which are time-consuming and less reliable.

Does the App Connect with Automation Tools Like Zapier and Make.com?

Integration with automation tools like Zapier and Make.com can help improve security. These tools allow you to set up automated backups, data transfers, and alerts that keep your information safe and accessible.

For example, you could create an automated workflow that saves a copy of your records every week to a separate cloud storage provider. These integrations also help you streamline processes, reducing human error and ensuring your data is always backed up properly.

Conclusion

Security should be a top priority when choosing a SaaS app. By looking for these key features, you can make sure your data stays protected, backed up, and easy to recover if something goes wrong. Taking the time to evaluate security now can prevent costly problems in the future.

Before committing to any SaaS app, run through this checklist. The right app should not only meet your business needs but also provide peace of mind that your data is secure. A little research now can save you from big headaches later.

In short: neither framework names a backup product, and neither one is satisfied by owning one. SOC 2's availability criteria (A1.2 and A1.3) and ISO 27001's Annex A 8.13 ask the same two questions: is backup governed by a written policy, and have you tested a restore? The current editions are the 2017 Trust Services Criteria with revised points of focus (2022) and ISO/IEC 27001:2022 with Amendment 1:2024. Every ISO 27001:2013 certificate expired on 31 October 2025. The backup obligation sits with your organisation, not with your SaaS vendors, and a vendor's SOC 2 report is supporting evidence rather than a substitute for your own.

Reviewed 24 September 2026. General information about two frameworks; how they apply depends on your scope, your auditor and your risk assessment.

What changed, and what did not

Most of what you read about "new SOC 2 requirements" or an "ISO 27001 2026 update" is not a change to the rules. Here is the actual state of both frameworks as of September 2026.

SOC 2: what is current

• What it is. An attestation engagement under AICPA standards. The output is an auditor's report carrying an opinion, not a certificate.
• Current criteria. The 2017 Trust Services Criteria with revised points of focus, published 2022 and posted by the AICPA in September 2023. There is no 2025 or 2026 replacement. AICPA
• Most recent change. The revised points of focus (2022), and the 2018 description criteria with revised implementation guidance (2022). Points of focus are explanatory examples, not criteria, so they do not change the controls you need. Description criteria
• Where backup sits. The availability criteria A1.2 and A1.3, with CC7.5 for recovery from incidents.

ISO 27001: what is current

• What it is. A certifiable management system standard. The output is a certificate issued by an accredited certification body.
• Current edition. ISO/IEC 27001:2022, published 25 October 2022. There is no 2026 edition. ISO
• Most recent change. Amendment 1:2024, published February 2024. It adds a requirement to determine whether climate change is a relevant issue, plus a note that interested parties may have climate-related requirements. ISO/IEC 27001:2022/Amd 1:2024
• A deadline that has already passed. 31 October 2025. All certifications based on ISO/IEC 27001:2013 expired or were withdrawn on that date under IAF MD 26.
• Where backup sits. Annex A 8.13, Information backup, supported by 5.29, 5.30 and 8.14.

Two practical consequences. First, if a vendor sends you an ISO 27001:2013 certificate in 2026, it is out of date and you should ask for the 2022 certificate and the certification body's accreditation. Second, if someone tells you SOC 2 has new backup requirements this year, ask which criterion. The criteria have not moved. What has moved is auditor practice, particularly around supplier scrutiny and how much evidence is expected for cloud services your organisation does not host.

The Annex A restructure from the 2022 edition still trips people up. The old 2013 control for backup was 12.3.1 and continuity lived in clause A.17. In the 2022 edition there are 93 controls in four themes: backup is 8.13, information security during disruption is 5.29, ICT readiness for business continuity is 5.30, and redundancy of information processing facilities is 8.14. Policies and statements of applicability that still quote 12.3.1 need updating.

The question both auditors ask first

Before any control language matters, both frameworks make you answer a scoping question: which systems are in scope, and is the data in your SaaS apps part of that scope?

For ISO 27001, that is the scope of your information security management system and the risk treatment behind your Statement of Applicability. For SOC 2, it is the system boundary described in section 3 of the report, written against the description criteria.

This is where most SaaS backup gaps originate. Teams scope their own product infrastructure carefully, then treat the CRM, the project management tool and the design files as someone else's problem because they run on a vendor's servers. If a business process depends on the records in those apps, and you would have to rebuild them by hand after a bad import, an auditor can reasonably expect the recovery of that data to be addressed somewhere in your control set.

The vendor's own availability commitment does not resolve this. Your SaaS provider protects its platform from its own failures. It generally does not undertake to reverse a deletion, a bad automation or a bulk edit made by your authorised users. That split is worth reading up on separately in our explanation of the shared responsibility model for SaaS data.

What your SaaS vendor's contract says

The clearest answer to "who backs this up?" is often in the vendor's own terms. Two examples, quoted from the current terms of service:

• ClickUp: "we encourage you to maintain your own backup of your Content. In other words, we are not a backup service and you agree that you will not rely on the Service for the purposes of Content backup or storage." (ClickUp Terms of Service)
• monday.com: "It is Customer's sole liability to export the Customer Data prior to such termination or expiration." (monday.com Terms of Service)

This is where ISO 27001 Annex A 5.23 bites. The control expects you to decide which security responsibilities sit with the cloud provider and which sit with you, and to plan how you would exit the service with your data. When the provider's contract puts backup on your side, your Statement of Applicability has to say how you discharge it.

SOC 2 handles the same situation differently. A SaaS tool you use internally is often outside the system your report describes, and where a vendor is in scope, the usual control is vendor management under CC9.2 rather than an independent copy. Backup becomes a SOC 2 question mainly when the SaaS app is part of the service you deliver, for example an agency running client work in ClickUp.

What SOC 2 actually asks of backups

SOC 2 is risk-based. There is no prescribed backup frequency, retention period or technology. The auditor tests the controls you described against the criteria in the categories you selected. Security is always included; availability, confidentiality, processing integrity and privacy are included when relevant to the service.

The criteria that touch backup, described generically:

• A1.2 (Availability). Environmental protections, software, data backup processes and recovery infrastructure are authorised, designed, developed, implemented, operated, monitored and maintained to meet availability objectives. In practice: you decided what needs backing up, the backup actually runs, someone watches whether it runs, and the copy is not sitting in the same failure domain as the original.
• A1.3 (Availability). Recovery plan procedures are tested to meet availability objectives. Having the plan is not the control. Exercising it is the control.
• CC7.5 (Security). The organisation identifies, develops and implements activities to recover from identified security incidents. After ransomware or a compromised integration, can you get back to a known-good state?
• CC9.2 (Security). Vendor and business partner risk management. This is where your review of the backup provider itself lands: their report, their subprocessors, their limitations.
• C1.2 (Confidentiality) and P4 (Privacy), where those categories are in scope, cover retention and disposal. Backups are copies of the same information, so a retention schedule that ignores them is incomplete.

Availability is the category that matters most here, and it is optional. If your report covers security only, an auditor may still reach backup through CC7.5 and your own stated controls, but the depth of testing differs. Decide deliberately whether availability belongs in your next report rather than discovering the gap when a customer's security questionnaire asks for it.

What ISO 27001 actually asks of backups

ISO 27001 splits into management system clauses (4 to 10) and the Annex A reference controls. Backup appears in both places, which is why "we bought a backup tool" never closes the finding on its own.

Annex A 8.13, Information backup expects backup copies of information, software and systems to be maintained and regularly tested in accordance with the agreed topic-specific policy on backup. Two load-bearing phrases: agreed topic-specific policy and regularly tested. The control assumes a written backup policy exists and that restores are exercised against it.

Supporting controls that auditors commonly pull in alongside it:

• 5.23, Information security for use of cloud services. New in the 2022 edition and directly relevant. It covers how cloud services are acquired, used, managed and exited, including what happens to your data.
• 5.29, Information security during disruption and 5.30, ICT readiness for business continuity. The continuity side: recovery objectives, plans and the readiness of the technology to meet them.
• 5.33, Protection of records and 8.10, Information deletion. Retention on one side, defensible deletion on the other.
• 8.14, Redundancy of information processing facilities. Availability of the processing capability itself, distinct from having a copy of the data.

Above Annex A, clause 6.1.3 requires you to justify each control's inclusion or exclusion in the Statement of Applicability, and clause 9 requires monitoring, measurement and internal audit. A backup control that is declared applicable but never measured is a nonconformity waiting to be written up.

On Amendment 1:2024: it is narrow. It adds a requirement under clause 4.1 to determine whether climate change is a relevant issue for your organisation, and a note under 4.2 that interested parties can have climate-related requirements. It does not create a backup requirement. It is reasonable, though, for a regionally concentrated backup strategy to come up when you document that determination, since extreme weather is one of the availability risks a single-region copy carries.

Mapping the obligation to the evidence

The same handful of artefacts satisfies both frameworks. Each line below gives one thing you must be able to show, the criterion or control it answers in each framework, and the evidence that actually holds up. Treat it as a practical starting point rather than a universal audit programme, and agree the specifics with your auditor.

• Backup is governed by a written, approved policy. SOC 2: A1.2, via your described controls. ISO 27001: A 8.13, which names an "agreed topic-specific policy", plus A 5.1. Evidence: the policy itself, with scope, frequency, retention, owner, approval date and review cycle.
• The systems in scope are actually backed up. SOC 2: A1.2. ISO 27001: A 8.13 and clause 6.1.3. Evidence: an app inventory naming each system, whether it is backed up, by what method, since when, and the documented reason for anything excluded.
• Restores are tested, not assumed. SOC 2: A1.3. ISO 27001: A 8.13, which says "regularly tested", plus A 5.30. Evidence: a dated restore-test record covering what was restored, by whom, elapsed time, what did not come back, the corrective action and the retest.
• Recovery objectives are defined and met. SOC 2: A1.2 and A1.3. ISO 27001: A 5.29 and A 5.30. Evidence: approved RPO and RTO per system, plus the measurements from your test compared against them.
• Access to backups is controlled. SOC 2: CC6.1 to CC6.3. ISO 27001: A 5.15 and A 8.2. Evidence: an access review of who can browse, export, restore or delete, MFA status, and the break-glass procedure.
• Backup copies are protected in transit and at rest. SOC 2: CC6.7. ISO 27001: A 8.24. Evidence: encryption configuration, storage region and a description of key management.
• Retention and deletion are deliberate. SOC 2: C1.2 and the P4 privacy criteria. ISO 27001: A 5.33 and A 8.10. Evidence: a retention schedule per data category with its justification, and how deletion requests reach backups, exports and restores.
• The backup vendor has been assessed. SOC 2: CC9.2. ISO 27001: A 5.19 to 5.23. Evidence: the supplier assessment, the vendor's current report, the subprocessor list, the DPA and the documented limitations.
• Incidents can be recovered from. SOC 2: CC7.5. ISO 27001: A 5.29. Evidence: the runbook, the incident record and the post-incident review.

Notice what is missing from the right-hand column: a screenshot of a connected integration. A screenshot proves a connection existed on the day it was taken. It does not evidence a tested recovery.

The four artefacts that do most of the work

If you are starting from nothing, build these four. Between them they answer the majority of backup questions in either audit.

1. A SaaS data backup policy. One document. Which apps are in scope, what is captured, backup frequency, retention per category and why, who owns it, how often restores are tested, who may restore, and what happens when a backup fails. Date it and have it approved. Our walkthrough of what belongs in a SaaS data backup policy covers the sections auditors look for.

2. A scope inventory. A table of every SaaS app the business depends on, its owner, whether it holds personal data, its native recovery options, whether it is independently backed up, and the decision recorded for anything deliberately left out. A documented exclusion is an acceptable audit answer. An undocumented gap is not. Our SaaS stack data protection audit is a five-step way to build this.

3. A restore-test record. The single highest-value artefact, because both A1.3 and A 8.13 name testing explicitly and it is the one most organisations cannot produce. One page per test is enough. See the section below.

4. An access review. Who can see the vault, who can export, who can restore, who can delete, and whether multi-factor authentication is enforced. Re-run it on the same cadence as your other access reviews and keep the output.

Running a restore test that satisfies both frameworks

A restore drill per quarter, documented, satisfies the "tested" element in both SOC 2 A1.3 and ISO 27001 A 8.13. Keep it small and real rather than large and theoretical.

1. Pick a representative scenario, not the easy one. "A project manager bulk-deleted a list of tasks last Thursday" beats "restore one record we deleted five minutes ago."
2. Restore to a safe destination using approved sample data, a test workspace or a supported non-destructive method, so the drill cannot itself cause an incident.
3. Check the things that break quietly. Custom fields, attachments, comments, assignees, relationships between records, permissions, and any automations that fire on record creation.
4. Time the whole workflow, from the moment someone notices to the moment the team can work again. Compare it with your stated RTO. If you have not set RPO and RTO yet, start with our explanation of what RPO and RTO mean for SaaS apps.
5. Write down what did not come back. Every integration has limits. Recording them honestly is stronger evidence than a clean report nobody believes, and it gives you a corrective action to close before the next test.
6. Sign, date and file it, with a named owner for each follow-up.

Our guide on how to test SaaS backups goes through the mechanics in more detail.

Retention, deletion and the awkward overlap with GDPR

Retention is where the two frameworks hand off to privacy law, and where a backup policy written purely for availability tends to fail.

Set retention by data category and purpose, not by whatever the product's maximum happens to be. Longer history is not automatically better: it enlarges the volume of personal data you hold and the blast radius of any compromise. Write down why each period is what it is, which records carry separate legal retention duties, and when old copies expire.

Then handle the harder direction. A validly erased record that a later restore quietly reintroduces into an active workflow is a real finding, and the control that prevents it is procedural. Make checking recovered records against your deletion log part of the restore runbook, and test that too. We cover the mechanics in GDPR and backups: how to handle deletion requests, and the wider legal picture in our guide to SaaS backup requirements under GDPR and NIS2.

If you are an in-scope NIS2 entity, backup management and disaster recovery are named obligations under Article 21(2)(c), assessed through your national implementing law. Start with NIS2 backup requirements.

Where a vendor's SOC 2 report fits, and where it stops

This is the most common misunderstanding in the whole subject, so it is worth stating plainly.

A backup vendor's SOC 2 Type II report evidences that the vendor protects the data it holds. Under GDPR Article 28 that is exactly the kind of assurance you are expected to check before appointing a processor, and under SOC 2 CC9.2 or ISO 27001 A 5.19–5.23 it is the evidence behind your supplier assessment. Read the scope, the period, the opinion and the listed exceptions rather than the badge.

It does not transfer your obligations. Your auditor will still ask you to show which systems are backed up, that retention matches your policy, that restores are tested, and that access is controlled. No vendor report answers those questions on your behalf.

For our own position: ProBackup has held a SOC 2 Type II report since May 2025, available under NDA through the trust centre and listed on our audit reports page. ProBackup does not hold ISO 27001 certification and does not claim it; if your policy requires ISO 27001 from every processor, that is a line item we do not meet today. The full detail is in what our SOC 2 Type II report covers.

If you run your compliance programme on Vanta, the ProBackup integration tests your ProBackup account continuously for deprovisioning, named accounts and MFA, which automates part of the access-review artefact above.

Five findings auditors actually write up

1. A policy with no evidence behind it. The document says quarterly restore tests. There are no test records. The policy becomes the finding.
2. Scope that stops at your own infrastructure. Production databases are covered in detail; the CRM holding every customer relationship is not mentioned anywhere in the Statement of Applicability or the system description.
3. "Version history" counted as backup. Native trash and version history are recovery features of the same platform, with their own retention windows and their own failure modes. They are worth having, and they are not an independent copy. See version history and trash retention across SaaS apps.
4. Nobody watches for failures. Backups silently stopped when an OAuth token expired three months ago. A1.2 expects monitoring, not just execution.
5. Retention set by accident. The plan's default was adopted because nobody chose a number, and it does not match the retention the policy claims.

Manual exports deserve a note of their own. A scheduled CSV export to a controlled location can form part of a compliant control set, and the old version of this article was too casual in implying that any copy will do. What auditors challenge is the surrounding evidence: is the export scheduled and monitored, is failure detected, is the destination access-controlled and encrypted, is retention enforced, and has a restore from it been tested? A manual process that depends on one person remembering usually fails the monitoring and testing tests rather than the copy test.

Your checklist

1. Confirm which framework and which categories apply. For SOC 2, decide whether availability is in scope. For ISO 27001, confirm your certificate is against the 2022 edition.
2. Put SaaS data inside the boundary. Name the apps in your Statement of Applicability or system description, with a documented reason for anything excluded.
3. Write or refresh the backup policy. Scope, frequency, retention, ownership, testing cadence, failure handling, approval date.
4. Set RPO and RTO per system, and check that the actual capture times and measured recovery times support them.
5. Choose the recovery method per app on the basis of the risk, then document the limits of what it can and cannot recover.
6. Run and document a restore test. Then schedule the next one.
7. Review access to backups and enforce MFA.
8. Reconcile retention and deletion across live data, backups, exports and restores.
9. Assess the vendor. Current report, scope, exceptions, subprocessors, DPA, storage region.
10. Update the Annex A references if your documentation still cites the 2013 control numbers.

FAQ

Does SOC 2 require backups?

Not by name, and not as a fixed rule. SOC 2 tests the controls you describe against the Trust Services Criteria you selected. If availability is in scope, criteria A1.2 and A1.3 cover data backup processes, recovery infrastructure and the testing of recovery procedures, so a backup control set is normally how organisations meet them.

Does ISO 27001 require backups?

Annex A 8.13, Information backup, expects backup copies of information, software and systems to be maintained and regularly tested in line with an agreed topic-specific policy on backup. Annex A controls are applied through your risk assessment and justified in the Statement of Applicability, so the depth is risk-based, but excluding backup entirely is difficult to defend.

Is ISO 27001:2013 still acceptable in 2026?

No. Under IAF MD 26, all certifications based on ISO/IEC 27001:2013 expired or were withdrawn on 31 October 2025. Current certificates are against ISO/IEC 27001:2022.

Did SOC 2 or ISO 27001 change in 2026?

Neither framework was rewritten. SOC 2 still uses the 2017 Trust Services Criteria with revised points of focus from 2022. ISO/IEC 27001:2022 remains the current edition, supplemented by the February 2024 climate-action amendment. There is no ISO 27001:2026 edition.

Does my SaaS provider's compliance cover my backups?

No. Your provider's certification covers its platform. It does not usually undertake to reverse deletions, bad imports or automation errors made by your own authorised users, and your auditor will ask about your controls, not only your vendors'.

Does using a SOC 2 certified backup vendor make my company compliant?

No. A vendor's report evidences how the vendor protects the data it holds, which supports your supplier assessment under CC9.2 or ISO 27001 A 5.19–5.23. Your own audit still requires your scope inventory, your policy, your tested restores and your access controls.

Are manual exports enough?

They can be part of a compliant control set, but they are judged on the same evidence as anything else: monitored execution, detected failures, controlled and encrypted storage, enforced retention, and a documented restore test. Processes that rely on someone remembering usually fail on monitoring and testing.

Pick one app that matters, confirm exactly what is backed up, and run a documented restore test this quarter. That single artefact answers more audit questions than any purchase does.

Start your ProBackup trial

Still comparing options? Review our data security documentation, plans and the Help Center to check coverage and recovery options for your apps.

In short: SaaS platforms such as Asana, ClickUp, monday.com, HubSpot and Trello recover from their own outages but not from your deletions, bad imports, offboarded users or AI agents editing records in bulk. Recycle bins last 7 to 90 days, miss overwritten fields and sit inside the same account. A real backup is daily, granular, versioned, independent, encrypted and tested.

Most teams assume the SaaS platform holding their data also protects it. That assumption is half right. Platforms such as Asana, ClickUp, monday.com, HubSpot and Trello run on hardened infrastructure and recover reliably from their own outages. What they don't do is recover your data from your own mistakes, your own integrations, or a user with the wrong permissions. This post explains where that gap sits, why it matters more in 2026 than it did two years ago, and what a working backup setup looks like. Updated August 2026.

The shared responsibility gap

Every major SaaS vendor operates on a shared responsibility model. The vendor is responsible for the platform: uptime, infrastructure security, and disaster recovery for their own systems. You are responsible for what happens inside your account. That includes accidental deletion, bulk edits gone wrong, a faulty import, an offboarded user, or an automation that ran on the wrong filter.

Most vendors are open about this in their terms, but few make it visible in the product. The result is that teams discover the boundary at the worst moment: after data is gone, when support explains that a permanently deleted board, record or project is outside their scope. We set out the hidden risks of SaaS data in more detail.

Key takeaway: a platform's disaster recovery protects the platform. It doesn't protect your account from you.

Why native recovery isn't a backup

Recycle bins and trash folders help with the simplest case: one item, deleted recently, noticed quickly. They fall short in three ways.

• Time-limited. Windows range from 7 to 90 days depending on the platform and plan, and permanent delete usually bypasses the bin entirely.
• No version history. If a record still exists but its fields were overwritten, there's nothing to restore. The bin only sees deletions, not corruption.
• Not independent. The bin lives inside the same account and the same permission model. Anyone who can delete can usually empty it too.

A backup is a separate copy, held outside the platform, versioned over time, that you control regardless of what happens inside the source account. Native recovery doesn't meet that bar.

The four ways SaaS data actually gets lost

1. Human error. Still the most common cause. Selecting the whole table instead of one row, choosing delete instead of archive, or removing a custom field along with every value it held.
2. Bad imports and integrations. A CSV with the wrong column mapping or a sync tool with a broken rule can overwrite thousands of records in minutes, and the platform logs it as a normal edit.
3. Malicious or careless users. A departing employee, a compromised login, or a contractor with admin rights. Trello, for instance, permanently deletes a board the moment a user with access confirms, with no bin to recover from.
4. AI agents acting at scale. New since 2025: agent features in ClickUp, monday.com, Asana and HubSpot can edit, enrol and delete records in bulk from a natural-language prompt. A misworded instruction reaches thousands of records before anyone reviews the result.

Ransomware belongs on the list too, but for SaaS platforms it mostly arrives through compromised credentials rather than encrypted servers, which puts it back in category three. We walk through five common data-loss scenarios and how to prevent them separately.

What good looks like

• Automated and daily. Any process that depends on someone remembering to export will lapse. Daily snapshots cap your maximum data loss, or recovery point objective (RPO), at 24 hours.
• Granular restore. You need to put back one task, one deal or one comment without rolling back the whole account. Whole-workspace restores are the exception, not the norm.
• Point-in-time history. Corruption is often noticed weeks later. Retention should stretch back far enough to find the last clean version.
• Stored independently and encrypted. Separate storage, AES-256 encryption at rest, TLS in transit, in a region you choose for data residency reasons.
• Tested. Run a restore drill every quarter. A backup you've never restored from is an assumption, not a control.
• Honest about scope. Backups work through each platform's public API. Where an API doesn't expose something, such as automations or certain metadata, no backup tool can capture it. Know your gaps before you need them.

Important context: for teams working under the General Data Protection Regulation (GDPR) Article 32, SOC 2 or ISO 27001, an independent, tested backup with defined retention is a control auditors expect to see, not just an operational nicety.

Where ProBackup fits

ProBackup is a SaaS backup service that takes automated daily snapshots of every app you connect and lets you restore individual records, files or whole projects back to the original account. Restores work in two modes: create new duplicate records, which leaves the originals untouched, or overwrite existing records field by field. Data is stored encrypted in the AWS region you select at signup, and ProBackup has been SOC 2 Type II certified since May 2025. Version history runs from 6 months on Plus to unlimited on Premium.

Conclusion

SaaS platforms have made infrastructure failures rare. They haven't made data loss rare; they've moved its cause from the server room to the people, integrations and agents working inside your account. That's the part the vendor doesn't cover, and it's the part a backup is for.

Written for IT managers, operations leads and anyone responsible for data governance in a team that runs on SaaS tools.

In short: In an August 2024 SafetyDetectives interview, ProBackup CEO Willem Dewulf explained that ProBackup grew out of losing Podio data the platform could not fully recover, that it focuses on project and CRM apps such as Trello, Asana and ClickUp rather than Office 365, backs up every 24 hours with no scheduling, and covers several apps under one subscription.

SafetyDetectives interviewed Willem Dewulf, CEO of ProBackup, in August 2024 about why the company was founded, how it differs from other backup tools, and the misconceptions teams have about backing up SaaS data. The interview is republished here; Willem's answers are as given at the time.

Can you share the story behind the founding of ProBackup? What inspired you to create this service?

The idea for ProBackup came from a personal experience. Years ago, we ran a SaaS company and used Podio for our internal project management. One day, one of our clients accidentally deleted a significant amount of data, including apps and accounts. When we tried to recover it, we discovered that Podio’s backup solution was inadequate. They could only provide a raw file with basic records, but none of the metadata, comments, or files were recoverable. That was a huge problem.

This experience made us realize the need for a robust backup solution. As a tech company, we decided to build one ourselves. That was about eight years ago. Over the years, we went through several iterations of our backup app for Podio, and around four years ago, we launched ProBackup as a dedicated service focused on providing quick and easy backup and restore solutions for popular SaaS apps. Our goal was to keep it simple, avoiding unnecessary functionalities and focusing on what really matters: backing up data and making it easily restorable.

What sets ProBackup apart from other data backup solutions on the market?

There are a few key differences. Firstly, most cloud backup solutions target major suites like Office 365, Google Workspace, Salesforce, or HubSpot. We, on the other hand, focus on popular project and CRM apps like Trello, Asana, and ClickUp. We aim to be the best in this niche rather than competing in the crowded Office 365 space.

Secondly, our app is incredibly easy to use. You can start backing up your cloud apps  in just a few minutes. We design our onboarding process to be as straightforward as using the apps we’re backing up, like Trello or Asana. Once connected, everything happens automatically. Backups run every 24 hours without the need for manual scheduling.

Finally, our pricing model is a significant differentiator. We offer a simple, transparent pricing structure with three plans: Plus, Pro, and Premium. Unlike our competitors, who often charge separately for each app integration, we allow you to back up multiple apps with a single subscription. This makes it easier for customers to understand what they’re paying for and offers great value without the complexity of managing multiple subscriptions.

What are some common misconceptions businesses have about data backups?

Two big misconceptions come to mind. First, many businesses assume that their cloud apps have built-in, foolproof backup solutions. They think, “If we delete something, the provider can recover it.” But that’s not always true. It’s surprisingly easy to permanently delete data in many apps. Additionally, some apps, like Trello, lack the necessary controls to limit actions by certain employees. For example: Anyone with access can delete a whole Trello board and empty the trash bin with just a few clicks, making the data irretrievably lost.

The second misconception involves the limitations of backing up through public APIs. We can only back up what the app’s public API allows us to access. This means certain data types, like automations or specific metadata, might not be backed up because they’re not available through the API. We strive to be transparent about these limitations with our customers, but it can still lead to disappointment when users expect a full, 100% backup.

How does ProBackup ensure data security, especially when dealing with sensitive company information?

Security is our top priority. From the start, we’ve made it a core part of our company culture. We use the latest encryption technologies and leverage the security features provided by AWS, as we store our data on S3. Internally, we follow strict security protocols. Access is tightly controlled, and all team members undergo regular training on data security. Even our admin access is restricted; we limit the number of accounts any admin can access daily, and we have alerts in place for any unusual activity. Most importantly, the majority of the data isn’t accessible to our team by default. We’ve designed our processes to minimize risk at every level.

How do you see AI and machine learning impacting the future of cloud backups?

For us, AI is mostly a tool to enhance productivity and speed up certain processes. We use AI to assist with coding and other tasks, but when it comes to data backups, we don’t see an immediate impact. Our data backups are highly secure, and we don’t view them as a data source for machine learning. The complexity involved in developing backup integrations for new SaaS apps still requires a lot of human input and understanding. We’re not at a point where AI can fully automate this process. So, while AI is valuable, we don’t currently see it revolutionizing our core backup functions.

What advice would you give to small businesses just starting to think about their data backup strategy?

It depends on the size of your business, but as soon as you start relying on any cloud app to manage your business, you should consider securing that data. Start by thinking about worst-case scenarios. In the beginning, manual exports on a weekly basis might suffice. But as you grow, switching to a daily automatic backup solution makes more sense. We’ve seen many small businesses come to us in panic after losing critical data, only realizing the importance of backups after the fact. Just like you wouldn’t wait to get car insurance after a crash, don’t wait to set up a backup after losing data. It’s crucial to have a plan in place from the start to avoid potential disasters.

In short: Yes, a GDPR erasure request also covers backups, but regulators accept technical limits. The EDPB's February 2026 report on the right to erasure found backup handling among the most common failures across 764 controllers. What is required is a documented, proportionate approach: defined retention, a deletion index so restored records are re-deleted, and clear communication to data subjects.

When we first published this guide in 2020, the intersection of GDPR and backups was a grey area, one that regulators were only beginning to address. Six years later, it is no longer grey. In February 2026, the European Data Protection Board (EDPB) published its landmark Coordinated Enforcement Framework (CEF) report on the right to erasure, drawing on investigations by 32 Data Protection Authorities (DPAs) across the EEA. The findings are clear: erasure compliance is now firmly in regulators' crosshairs, and backup systems are explicitly on the list of concerns.

This updated guide incorporates the latest regulatory guidance, real-world enforcement findings, and practical operational advice for any organisation running backups of personal data. Whether you use ProBackup to protect your SaaS workspace data, or manage backups in-house, this article will help you build a defensible, GDPR-compliant approach.

Why GDPR and backups are a difficult combination

Backups exist precisely because data must not be lost. GDPR's right to erasure exists precisely because data must, in some circumstances, be deleted. These two requirements are structurally in tension, and that tension is not fully resolved by any single piece of guidance, including this one.

The practical difficulty is this: a backup tape or snapshot is designed to be a complete, point-in-time copy of a system's data. Surgically removing one individual's records from that snapshot is often technically impossible without restoring the entire backup, making the deletion, and then re-backing up. That is expensive, slow, and disruptive to the very purpose the backup serves.

GDPR regulators understand this. Their guidance consistently acknowledges the technical constraints. But understanding a constraint is not the same as exempting an organisation from the underlying obligation. The EDPB's February 2026 CEF report noted that difficulties with backup deletion were among the most common compliance failures observed across 764 controllers surveyed, ranging from no procedures at all to reliance on simple overwrite cycles with no documented rationale.

The legal framework: what the GDPR actually requires

Article 17: the right to erasure ('right to be forgotten')

Article 17 GDPR gives individuals the right to request deletion of their personal data when any of the following conditions apply:

• The data is no longer necessary for the purpose for which it was collected
• The individual withdraws consent (where consent was the lawful basis) and there is no other legal ground
• The individual objects to processing and there are no overriding legitimate grounds
• The data was processed unlawfully
• Deletion is required to comply with a legal obligation
• The data was collected in relation to an offer of information society services to a child

Article 5(1)(e): storage limitation

Personal data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which it is processed. Once the purpose is fulfilled, or where no purpose remains, the data must be deleted or anonymised. This applies equally to live systems and backups.

Article 30: records of processing activities

Your Record of Processing Activities (RoPA) must document the envisaged time limits for erasure of each data category. If your backup retention schedule contradicts the deletion periods in your RoPA, you have a compliance gap that DPAs are specifically looking for.

Article 12(3): the one-month timeline

Erasure requests must be acted upon without undue delay and within one month of receipt. Controllers may extend this by a further two months where requests are complex or numerous, provided they inform the data subject of the extension within the first month.

Important: The one-month clock applies to the response, not necessarily to the physical deletion from every storage layer. Transparency about what has been done, and what will be done when, is what the law demands for backup-layer data.

The EDPB's 2026 findings: what regulators now expect

The EDPB's CEF 2025 action on the right to erasure, the results of which were published in February 2026, is the most authoritative signal yet of what regulators consider compliant practice. Here are the key findings most relevant to backup systems:

Backup handling was a widespread failure

DPAs found a wide spectrum of practices. Some controllers had no procedures at all for erasure in backups. Others relied solely on automatic overwrite cycles with no documented policy or communication to data subjects. The EDPB specifically called out these approaches as inadequate.

The EDPB identified one best-practice model

One approach stood out in the report as exemplary: a controller that, upon reaching a data subject's retention end date, automatically extracted all personal data relating to that individual from all systems, moved it to an access-restricted environment, and permanently deleted it one month later. Some controllers also replaced personal data fields with random characters, achieving functional erasure within the backup structure without restoring the backup.

Anonymisation is often insufficient

Many controllers claimed to anonymise data as an alternative to deletion. DPAs found that most of these techniques were in practice only pseudonymisation, reversible masking that does not prevent re-identification. True anonymisation removes data from GDPR's scope entirely. The EDPB is currently developing new anonymisation guidelines following the CJEU's September 2025 ruling in Case C-413/23P (EDPS v. SRB). These guidelines will be critical for any organisation relying on anonymisation as an erasure alternative.

The volume of erasure complaints is rising

In the Netherlands, 580 complaints in 2024, 18.6% of all DPA complaints, related to the right to erasure. In Ireland, more than 3,000 erasure complaints have been filed since GDPR came into force. Spain has received over 7,000 such complaints. This is not a niche issue.

Enforcement will intensify in 2026

Multiple DPAs (including CNIL (France), the Portuguese CNPD, and the Swedish IMY) have confirmed that the CEF findings will inform sector-specific inspections and supervisory planning in 2026. Nine DPAs launched or continued formal investigations as part of the 2025 action, with proceedings ongoing in Ireland, France, Portugal, Slovenia, and Germany.

Does a deletion request include removing data from backups?

Yes, but with important practical nuances that regulators have consistently acknowledged.

The Danish Data Protection Authority (Datatilsynet) has stated that deletion from backups is mandatory 'if this is technically possible.' The French CNIL has long held that data deleted from production systems may remain in backups temporarily, provided the organisation clearly communicates this to the data subject in plain language and specifies the retention time.

The UK Information Commissioner's Office (ICO) uses the concept of putting data 'beyond use.' For backup data that cannot be immediately overwritten, this means:

• The backup is not accessed for any operational purpose
• No one can retrieve and use the backed-up data
• The data will be deleted when the backup is next refreshed or overwritten on a documented schedule
• The organisation is transparent with the data subject about this timeline

The ICO also distinguishes between offline archiving and live backups, but critically, archiving offline is still processing under GDPR. It only remains lawful if you can justify it with a lawful basis.

What this means in practice: When you receive a valid deletion request, you should delete the data from your live systems immediately. For backup data, document the earliest point at which the backup containing that data will expire or be overwritten, and communicate this to the data subject. Then ensure the data is not accessed or restored in the interim.

The 'zombie record' problem: what happens when you restore a backup?

The second core problem, and one that has bitten many organisations, is the restoration scenario. Suppose a user's data has been legitimately deleted following an erasure request. Six months later, you suffer a data loss event and restore from a backup that pre-dates the deletion. That user's records are now back in your live system. You are immediately non-compliant.

This is not a hypothetical. It happens routinely in organisations that have not built a deletion-aware restore process.

The deletion index: the industry-standard solution

At ProBackup, we have always advised teams to maintain what we call a deletion index. Here is how it works:

• When you action an erasure request, you record a non-identifiable marker (such as a database row ID, a hashed identifier, or an internal record number, not the personal data itself) alongside the date of deletion
• That record is retained for as long as any backup exists that could contain the original data
• Your restore process includes a mandatory post-restore step: run the deletion index against the restored dataset and re-delete any records flagged for erasure
• Document this process in your data protection documentation

This approach was implicitly endorsed in the EDPB's 2026 report, which noted the best-practice examples involved tools that tracked data subject retention end dates and applied automated deletions at the point of expiry.

GDPR-compliant retention periods for backup data

GDPR does not prescribe specific retention periods. It requires organisations to justify the period they choose based on the purpose of the data and any applicable legal obligations. The storage limitation principle under Article 5(1)(e) is the controlling rule: keep data no longer than necessary.

In practice, backup retention periods are often shaped by:

• Operational recovery needs: How far back do you realistically need to restore?
• Contractual or regulatory obligations: Do sector-specific rules mandate minimum retention?
• Legal exposure windows: The applicable limitation period for claims in your jurisdiction
• Cost and proportionality: Is the marginal compliance benefit of very long retention worth the increased data protection risk?

Common reference points from other applicable laws (which must be balanced against GDPR's minimisation principle) include:

These are indicative references only. Every organisation must document and justify its own retention schedule in its RoPA. The EDPB's 2026 report specifically criticised controllers for failing to define and document retention periods, calling this one of the seven systemic weaknesses identified across the survey.

Communicating with data subjects about backup retention

Transparency is a first principle of GDPR. Articles 13 and 14 require controllers to inform data subjects (at the point of collection) about the envisaged period for which their data will be stored, or the criteria used to determine that period.

When it comes to backups, this means your privacy notice should not be silent on the subject. The CNIL guidance from 2018, which remains the most widely-cited practical standard, says organisations must explain in clear and plain language:

• That data has been removed from production systems
• That a backup copy may remain temporarily
• The specific retention time of that backup (or the earliest point at which the backup will expire)

Here is a suggested template paragraph for your privacy notice:

"When we receive a valid request to delete your personal data, we will remove it from all live systems without undue delay. Your data may remain in encrypted backup copies for up to [X weeks/months], after which it will be automatically overwritten or deleted in accordance with our backup retention schedule. During this period, your data is not accessible for any operational purpose and will not be restored to live systems. You will receive a confirmation of deletion from our live systems within [X days] of your request, together with this explanation regarding backup retention."

This level of transparency achieves two things: it satisfies your Article 12 and 13 obligations, and it sets realistic expectations for data subjects that reduce the likelihood of complaints to DPAs.

Practical compliance checklist for backup systems

Based on the EDPB's 2026 findings and our own experience supporting thousands of teams at ProBackup, here is the operational checklist every organisation should work through:

Documentation

• Your RoPA documents the retention period for every category of backed-up data
• Your backup retention schedule is aligned with (and does not exceed) the deletion periods in your RoPA
• You have a written internal policy describing how erasure requests are handled in the context of backups
• Your privacy notice discloses backup retention timelines in plain language

Process

• You have a formal intake process for erasure requests (verbal or written requests both qualify, no 'magic words' are required by the ICO)
• You verify the identity of the requesting individual before acting
• You delete from live systems within one month of receipt
• You maintain a deletion index using non-identifiable markers
• Your restore procedure includes a mandatory post-restore deletion step based on the index
• You inform any third-party processors (including your backup provider) of applicable erasure requests

Technical

• Backup access is restricted to restore-only scenarios, no operational querying of backup data
• Your backup encryption keys are managed such that key destruction could, where practical, render data irrecoverable
• Where you use anonymisation as an erasure alternative, you have verified it constitutes true anonymisation (not merely pseudonymisation)
• Automated retention expiry is in place where technically feasible

Accountability

• You log erasure requests and record the steps taken, the systems affected, and any backup-layer timeline communicated to the data subject
• You can produce this log on request from a DPA
• Your retention schedule is reviewed at least annually

When you can refuse or delay an erasure request

The right to erasure is not absolute. Article 17(3) sets out the exceptions. You may retain personal data, including in backups, where processing is necessary for:

• Compliance with a legal obligation under EU or Member State law (e.g., statutory accounting or tax records)
• The establishment, exercise or defence of legal claims
• Reasons of public interest in the area of public health
• Archiving purposes in the public interest, or scientific, historical or statistical research, subject to appropriate safeguards
• The exercise of the right of freedom of expression and information

The most commonly invoked exception in practice is legal obligation and defence of legal claims. Where this exception applies, document your reasoning explicitly. The EDPB's 2026 report found that controllers frequently misapplied exceptions, citing them without adequate justification. This is itself a compliance failure.

How ProBackup supports GDPR-compliant data management

At ProBackup, we back up SaaS workspaces, Asana, ClickUp, monday.com, HubSpot, Jira, Notion, Slack, and more, for thousands of teams across Europe. GDPR compliance is not an afterthought for us; it is built into how our product works.

Granular, point-in-time snapshots

Our daily snapshots create discrete restore points. This means that when a deletion request is actioned in your SaaS workspace, you can identify exactly which backup generations contain the affected data, and plan your retention timeline accordingly.

Defined retention windows

ProBackup gives you control over how long backup data is retained. We recommend aligning your ProBackup retention window directly with the backup retention periods disclosed in your privacy notice. When the retention window closes, the data is permanently removed from our systems.

Security architecture

All ProBackup data is encrypted at rest with AES-256 and in transit with TLS. Access to backup data is restricted and audited. ProBackup is SOC 2 Type II certified, which means our security controls, including access to backup data, have been independently verified.

Data processing agreement

As a data processor under GDPR, ProBackup provides a Data Processing Agreement (DPA) to all customers. This DPA formally documents our obligations in relation to the personal data we process on your behalf, including our obligations to assist you in responding to data subject rights requests.

Deletion support

When you action an erasure request and need to understand what backup generations may contain the affected data, our support team can assist. We can advise on the precise retention window for your account and confirm the date by which a given backup will expire.

Conclusion: the regulatory direction of travel is clear

When we wrote the original version of this article in 2020, many organisations were still treating GDPR backup compliance as a theoretical concern. The EDPB's February 2026 report (the most detailed, evidence-based regulatory assessment of erasure compliance yet produced) confirms that those days are over.

Thirty-two DPAs investigated 764 controllers. They found widespread inadequacy. Backup handling was singled out as one of the seven systemic challenges. And multiple DPAs have now confirmed they will use these findings to drive sector-specific enforcement in 2026 and beyond.

The good news is that the compliance path is well-defined. You do not need to surgically remove data from every backup in real time. You do need a documented retention schedule, a deletion index, a transparent privacy notice, and a restore procedure that includes re-deletion of flagged records. These are achievable for organisations of any size.

At ProBackup, we are committed to making this as operationally straightforward as possible for our customers. If you have questions about how your ProBackup configuration aligns with your GDPR obligations, our team is available to help.

Sources and further reading

• EDPB CEF 2025 report on the right to erasure (February 2026), edpb.europa.eu
• ICO guidance on the right to erasure, ico.org.uk
• CNIL guidance on backups and erasure, cnil.fr
• heyData, GDPR data retention periods: key rules and best practices (January 2026), heydata.eu
• Danish Datatilsynet, guidance on backup and the right to erasure, datatilsynet.dk
• GDPR Regulation (EU) 2016/679, Articles 5, 12, 13, 17 and 30, gdpr-info.eu
• Reed Smith, EDPB CEF 2025 report analysis (March 2026), reedsmith.com

Disclaimer: This article is for informational purposes only and does not constitute legal advice. For advice specific to your organisation's circumstances, consult a qualified data protection professional.

We back up SaaS data for organisations across Europe and beyond, and we work with a Belgian data privacy specialist to keep our own practices current. This is our mid-year reset: what's in force, what's proposed, and what either way means for how you run backups.

The short answer

If you read nothing else, these are the five points that matter for backup as of July 2026.

• The GDPR's 72-hour personal data breach notification deadline is unchanged. The proposed extension to 96 hours sits in the half of the Digital Omnibus that is still being negotiated.
• Article 32 still requires you to restore personal data in a timely manner, and to test that you can. Nothing in the Omnibus touches that. It remains the load-bearing legal obligation behind any backup programme.
• NIS2 has moved from a transposition problem to an enforcement one. The Commission referred four Member States to the Court of Justice in July 2026, and national authorities have started auditing.
• The AI half of the Omnibus is law. High-risk obligations under the EU AI Act shifted to December 2027 and August 2028, but the transparency rules still start on 2 August 2026.
• Data subject rights still reach into your backup copies. Erasure, access and rectification requests have to be handled across live systems and snapshots alike.

Where the shared responsibility model leaves you

Before the regulatory detail, the thing that trips up most teams. Your SaaS vendor backs up their own infrastructure so they can recover from their disasters. That's the whole scope of it. They are not backing up your account so you can recover from yours.

If someone on your team deletes a board, if a broken integration overwrites a thousand records, if a departing employee wipes a project, or if an AI agent bulk-edits a workspace overnight, the vendor's infrastructure redundancy does nothing for you. The data was deleted through the application, exactly as the application is designed to allow. There is no outage to recover from.

That gap is yours to fill, and under the GDPR it is a legal obligation rather than a preference. When you back up a SaaS platform, you're copying personal data: contacts in HubSpot, task assignees in Asana, customer messages in Slack. Those copies inherit every obligation attached to the originals.

Article 32 makes restore a legal requirement, not a best practice

The most direct GDPR reference to backup sits in Article 32, security of processing. It requires appropriate technical and organisational measures, including the ability to ensure ongoing availability and resilience of processing systems, the ability to restore availability and access to personal data in a timely manner after an incident, and a process for regularly testing and evaluating whether those measures actually work.

Three obligations fall out of that.

You have to be able to restore personal data

Not "should be able to". If personal data is lost through accidental deletion, ransomware, a platform fault or a runaway automation, restoring it is your responsibility. Human error, malicious insiders, technical glitches and ransomware are the four routes to data loss we see most often, and none of them is covered by your vendor's infrastructure backups.

Restoration has to be timely

Article 32 says "in a timely manner" without defining it, which regulators read in context. The context is a 72-hour breach notification clock. If you can't establish what was lost and get it back before that deadline, your recovery point objective has become a compliance question rather than an IT one.

You have to test

Article 32(1)(d) requires regular testing of the effectiveness of your measures. An untested backup isn't a compliant backup, and supervisory authorities do ask for evidence during breach investigations.

What the Digital Omnibus actually did, and didn't, change

The European Commission published the Digital Omnibus on 19 November 2025 as a simplification package touching the GDPR, the ePrivacy regime, the Data Act, the Data Governance Act, NIS2 and the AI Act. It is not one instrument. It is two, and they have come apart.

The AI Omnibus completed the legislative process: Parliament approved the text on 16 June 2026, the Council gave final approval on 29 June 2026, and publication in the Official Journal was expected in July 2026.

The Data Omnibus, which carries the GDPR, ePrivacy, NIS2 and DORA amendments, has not. The Cypriot Presidency pulled its compromise text from the COREPER II approval process in the last days of June 2026 after it became clear it lacked a qualified majority, and the file passed to the Irish Presidency on 1 July 2026 without a Council position. Commentators' estimates for adoption now range from late 2026 to mid-2027, and several of the Commission's original simplification measures have already been weakened or removed in the Council's working text.

So the changes most often quoted at backup and incident response teams are proposals, not law.

‍

The AI Omnibus is law, and it moves your AI Act dates

This one matters for anyone running AI agents inside their SaaS stack.

• Stand-alone high-risk systems under Annex III now have until 2 December 2027, rather than 2 August 2026. That is a 16-month extension.
• High-risk AI embedded in regulated products under Annex I moves from 2 August 2027 to 2 August 2028.
• Article 50 transparency obligations were not deferred. Telling people they're interacting with an AI system, and labelling AI-generated content, still applies from 2 August 2026.
• Watermarking for synthetic media systems already on the market before that date gets a short extension to 2 December 2026.
• The deadline for Member States to establish AI regulatory sandboxes moved to 2 August 2027.

Read that as a longer runway for compliance work, not a reprieve. And note what didn't move at all: your GDPR obligations over the data those agents are touching.

Agentic AI, meaning AI that acts on your data rather than just describing it, is now built into monday.com, ClickUp and most of the platforms teams run their operations on. An agent can create, modify, reorganise and delete records at machine speed, and a badly scoped instruction can propagate through a workspace before anyone opens the app. We go into the mechanics of that in our article on agentic AI and the importance of SaaS backup.

From a compliance angle, an independent point-in-time backup does two jobs here. It gives you a tamper-resistant record of what the data looked like before an agent touched it, which is what you need when you have to reconstruct what happened. And it gives you the ability to reverse the change, which is what you need to meet Article 32.

NIS2 has moved from transposition to enforcement

The NIS2 Directive had a transposition deadline of 17 October 2024. Most Member States missed it, and the gap has now become an enforcement story.

The Commission opened infringement proceedings against 23 Member States in November 2024, issued reasoned opinions to 19 in May 2025, and referred Ireland, Spain, France and the Netherlands to the Court of Justice in July 2026. The Dutch Cyberbeveiligingswet enters into force on 15 August 2026. Germany's BSI has begun auditing registered entities. In June 2026 the NIS Cooperation Group published the most detailed Article 21 mapping document produced so far.

An important point that gets missed: infringement proceedings against a government do not create a grace period for the entities that government was supposed to regulate. The obligations bind in-scope organisations regardless of where their national law has got to.

What NIS2 asks of your backups

• Business continuity. Article 21(2)(c) lists backup management and disaster recovery as required risk management measures, explicitly.
• Supply chain security. Article 21(2)(d) covers the security of your direct suppliers and service providers, which includes your backup vendor.
• Incident reporting. Article 23 sets a 24-hour early warning, a 72-hour notification and a final report within one month. The early warning is tighter than anything in the GDPR.
• Management accountability. Under Article 20, management bodies approve and oversee these measures and can be held liable. Several national implementations, including Italy's and Germany's, provide for personal consequences for directors.

One further item for the watch list: on 20 January 2026 the Commission proposed a targeted NIS2 amendment that would add ransomware payment disclosure obligations under Article 23 and require non-EU entities in scope to designate an EU representative. If adopted, Member States get a year to transpose it, which means national NIS2 laws will be revised again.

NIS2 and GDPR are not interchangeable

Compliance with one doesn't give you the other. Where the GDPR protects personal data and individual rights, NIS2 targets systemic cyber risk and operational resilience. Non-EU organisations may need a representative under both, and those are different roles with different demands. A GDPR representative mostly handles documentation and correspondence. A NIS2 representative has to be able to support technically complex incident communications inside a 24-hour window. Assigning both to the same outsourced provider without checking they have real security capability is a common and expensive mistake.

Data subject rights and your backup copies

A backup is a point-in-time copy designed to be preserved and restored, not edited. Data subject rights don't respect that design, and this remains the hardest part of backup compliance.

The right to erasure

Under Article 17, an individual can ask you to delete their personal data. Under Article 12(3) you have to respond without undue delay and in any event within one month of receipt, extendable by two further months where the request is complex. If you keep 30, 90 or 365 days of snapshots, every one of them still contains that person's data.

The generally accepted regulatory position is that you don't have to purge every historical snapshot on receipt. What you do have to ensure is that the data isn't quietly resurrected: if you restore from a backup taken before the request, the erasure has to be reapplied. That makes it a workflow problem, not a storage problem.

The right of access

Individuals can ask for a copy of the personal data you hold, and in principle that includes backups. Same one-month clock. The practical question to ask any provider is whether you can actually search a backup archive for one person's records, or whether you'd be reconstructing an entire snapshot to answer a single request.

The right to rectification

If someone corrects their data, a later restore shouldn't undo the correction. Your restore procedure needs a step that catches this.

Controller, processor, sub-processor

Most organisations using a backup tool sit in more than one of these roles depending on which data you're looking at.

The old assumption that processors carry minimal liability is gone. Regulators now treat liability as shared across the chain, and the largest fines on record have concerned exactly this territory. If your provider's misconfiguration or weak defaults cause a breach, they are exposed alongside you. Vendor due diligence is a primary compliance obligation now, not paperwork.

Vetting a third-party backup provider

Outsourcing backup doesn't outsource the obligation. Here's what we'd want answered before signing anything, and what we expect to be asked ourselves.

Security architecture

• Is data encrypted at rest with AES-256, and in transit with TLS 1.2 or better?
• Is role-based access control enforced, and are data access events logged?
• Are they SOC 2 Type II certified or ISO 27001 certified, and can you see the report?
• Have they had independent penetration testing, and when?

Data location

• Where are backups physically stored, and can you choose the region?
• Who are the sub-processors, and how much notice do you get before the list changes?
• If anything leaves the EEA, what transfer mechanism covers it, and has a transfer impact assessment been done?

Data subject rights support

• Can the provider find and remove one specific user's data from backups?
• Can they help you answer an access request that touches archived data?
• What happens to your backups when the contract ends?

Breach notification

• What is their contractual notification deadline to you, and does it leave you enough time to meet your own 72-hour obligation?

Data residency and international transfers

Chapter V of the GDPR governs any transfer of personal data outside the EEA, including transfers that exist only because of where a backup happens to be stored.

Adequacy and the EU-US framework

The EU-US Data Privacy Framework, adopted in July 2023, remains valid law. The General Court dismissed the first direct challenge to it on 3 September 2025, finding the Data Protection Review Court sufficiently independent and US bulk collection limits adequate. That judgment was expressly confined to the facts as they stood in July 2023.

The story didn't end there. The applicant appealed to the Court of Justice on 31 October 2025, and as of mid-2026 that appeal is pending with no hearing date announced. The Court of Justice, not the General Court, is the body that struck down both Safe Harbor and Privacy Shield. Treat the framework as valid today and structurally uncertain over a three-year horizon.

Standard contractual clauses

For destinations without an adequacy decision, the 2021 SCCs remain the mechanism. Regulators are increasingly examining whether transfer impact assessments were genuinely carried out rather than filed.

Residency controls

The cleanest answer for an EU organisation is to keep backup data in the EEA and avoid the transfer question altogether. Ask specifically whether EU-region storage is standard or an enterprise upsell, and whether you can choose the region rather than accept a default.

Backup retention against storage limitation

Article 5 says personal data should be kept only as long as necessary. Backup exists to keep data available for a period. That tension is real, and regulators have accepted that backup data can sit outside normal deletion schedules provided the retention is defined and documented rather than accidental.

Your retention policy should state how long snapshots are kept, whether any longer-term archive exists and why, how backup retention relates to the underlying data's schedule, and what happens to snapshots when the source data is deleted.

Treat retention as a decision you made rather than a setting nobody looked at. If you can't explain why the number is what it is, it's probably too high, and it belongs in your record of processing activities with a justification attached.

Beyond Europe

If you operate outside the EU, parallel obligations apply.

• United Kingdom. The UK GDPR mirrors the EU position on backup, enforced by the Information Commissioner's Office. Non-UK organisations targeting UK individuals need a separate UK representative.
• United States. There is still no federal privacy law. Around 20 states have a comprehensive consumer privacy law in force as of mid-2026, with several more enacted and not yet effective. All of them carry deletion, security and portability obligations that reach backup data. State attorneys general have become notably more active.
• Switzerland. The revised Federal Act on Data Protection has one feature worth knowing about: fines are levied against responsible individuals rather than the company, up to CHF 250,000 for intentional violations.
• Australia, Canada, Singapore and Japan each have security-of-processing obligations broadly analogous to Article 32.

Building to the GDPR standard gets you most of the way to the rest. It is still the most demanding of the major regimes, and organisations that are genuinely compliant in their backup practices generally find the others follow.

Five things that most often go wrong

1. Planning against proposals. Teams that rewrote their playbooks for a 96-hour window and a single reporting portal now have procedures that don't match the law. Check whether anything in your incident response plan cites the Digital Omnibus as though it were in force.
2. Backups that have never been restored. The single most common finding. The backup job runs green for two years and nobody has ever pulled anything out of it.
3. No link between erasure requests and restores. Data gets deleted on request, then quietly restored months later during an unrelated recovery, and nobody notices.
4. Retention set once and forgotten. "We keep everything" is not a retention policy, and under Article 5 it's a liability.
5. A DPA signed years ago and never reopened. Agreements drafted before the current enforcement posture often lack sub-processor notice terms, breach notification deadlines that fit your own obligations, and clear exit provisions.

What good looks like

• A written backup policy with a named owner, reviewed annually, that states retention per data category and the reasoning behind it.
• Restore tests at least quarterly, with results written down: date, scope, duration, outcome.
• A recovery time objective you have actually measured, sitting comfortably inside your 72-hour notification window.
• A deletion request log that is checked before every restore.
• Backup data held in the EEA, or a documented transfer mechanism if it isn't.
• A current DPA covering data categories, retention, sub-processors, audit rights, breach notification timing and what happens at termination.
• Backup frequency matched to how fast your data actually changes, including any AI agents operating in the workspace.
• An incident response plan that names backup restore as a recovery step and says who owns it.

Your compliance checklist

A starting point for reviewing your own programme. It isn't legal advice, but it covers what regulators generally expect to see documented.

Infrastructure

☐  Backup frequency meets your recovery point objective

☐  Encrypted at rest (AES-256 or equivalent) and in transit (TLS 1.2+)

☐  Role-based access control, minimal access by default

☐  Access events logged

☐  Backups stored separately from primary data

☐  EU personal data held in the EEA, or a lawful transfer mechanism is in place

Testing and governance

☐  Restores tested at least quarterly, results documented

☐  Recovery time objective defined and achievable inside 72 hours

☐  Backup policy reviewed annually and signed off by a named person

☐  Retention defined per data category and recorded in your ROPA

☐  Incident response plan references restore and assigns ownership

Data subject rights

☐  Deletion request log exists and is checked before any restore

☐  Restore procedure prevents overwriting post-request corrections

☐  Provider can support user-level searches across backup data

Third parties

☐  Current signed DPA with your backup provider

☐  Sub-processor list reviewed, and notice period agreed in the contract

☐  Provider breach notification deadline supports your 72-hour obligation

☐  Provider certifications (SOC 2 Type II, ISO 27001) reviewed and current

NIS2, if in scope

☐  You have assessed whether you fall within NIS2 scope

☐  Backup and disaster recovery documented under Article 21 risk management

☐  GDPR and NIS2 representatives appointed separately where required

☐  Incident procedures reflect the 24-hour early warning, not just the GDPR clock

How ProBackup approaches this

ProBackup is a SOC 2 Type II certified backup and restore tool for SaaS platforms including Asana, ClickUp, monday.com, HubSpot, Jira, Notion and Slack. Our parent company is headquartered in Belgium, and we work with a Belgian data privacy specialist to maintain our compliance posture.

We're honest about the limits. We can only back up what a platform's API exposes, which means some data types are out of reach on some platforms, and we say which ones on each platform page rather than claiming we capture everything.

Plans scale with data usage and start at $25 per month billed yearly. You can see the full breakdown on our pricing page, read how other teams have recovered from deletions in our success stories, or review our audit reports and GDPR documentation.

What has actually changed since 2020

Our original guide reduced the GDPR's backup obligations to three points: backup is legally required, backups have to be current, and your provider has to be compliant. All three still hold. What's different is the weight around them.

• Enforcement is heavier. European regulators issued roughly EUR 1.2 billion in GDPR fines during 2025, taking cumulative penalties past EUR 7 billion since 2018, according to DLA Piper's January 2026 survey.
• NIS2 runs alongside the GDPR with its own backup, supply chain and incident reporting duties, its own representative requirement, and a 24-hour early warning that the GDPR doesn't have.
• Liability is shared down the chain. Your backup provider carries real exposure, which makes their security posture part of yours.
• AI agents now operate inside the platforms holding your personal data, and the AI Act's core obligations have been pushed out to late 2027 rather than arriving this August.
• The reform everyone expected has not arrived. As of July 2026 the GDPR half of the Digital Omnibus is still a proposal without a Council position.

That last point is the practical one. There's an understandable urge to hold off on compliance work while the rules are being rewritten. It's the wrong read. The parts of the law that govern backup, the duty to restore and the duty to prove you tested it, aren't the parts under negotiation. They've been stable since 2018 and they are what a supervisory authority will ask you about.

Go and run a restore test. Write down what happened. That's a better use of the next hour than watching the Council.

This article is written for IT decision-makers, compliance officers and data protection professionals. It reflects the regulatory position as of July 2026 and is not legal advice. For guidance on your own situation, speak to a qualified data protection professional.