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
- 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.
- 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.
- No link between erasure requests and restores. Data gets deleted on request, then quietly restored months later during an unrelated recovery, and nobody notices.
- Retention set once and forgotten. "We keep everything" is not a retention policy, and under Article 5 it's a liability.
- 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.
