How Should B2B SaaS Handle GDPR Deletion Requests? (2026)

How should B2B SaaS handle GDPR deletion requests? Treat every request as a repeatable workflow: log it, verify the requester, work out whether you are controller or processor, delete the data everywhere it lives, notify every processor, and reply within one month. The rest of this guide shows how, system by system.

This guide is written for founders, CTOs and heads of engineering at B2B SaaS companies that sell to customers in the EU and UK, including US teams that assumed GDPR was somebody else's problem. The stakes are not abstract. In February 2026 the EDPB published the results of an enforcement action on erasure covering 764 organisations, and fines for ignoring data subject rights reach €20 million or 4 percent of worldwide turnover.

We read the pages that rank for this question before writing this one. They cover the basics well. They skip the runbook, the system-by-system deletion methods, the B2B offboarding case and what the EDPB's 2026 findings mean for your backlog. Those are the parts below.

What Does GDPR Article 17 Require From a B2B SaaS Company?

GDPR Article 17, the right to erasure, requires a controller to delete a person's personal data without undue delay when one of six grounds applies, unless a listed exception lets it keep the data. For a B2B SaaS company, that reaches far beyond a user profile row.

Article 17(1) sets out the grounds. SaaS teams run into these most often:

• No longer necessary. The data is not needed for the purpose you collected it for, such as a trial user who never converted.
• Consent withdrawn. Consent was your only legal basis and the person pulled it, for example a newsletter subscriber.
• Objection. The person objects to processing based on legitimate interests and nothing overrides that, or objects to direct marketing.
• Unlawful processing. The data should never have been collected or kept in the first place.
• Legal obligation. EU or Member State law requires you to erase it.
• Child's data. The data was collected from a child in connection with online services.

B2B does not get a pass. A work email such as name@company.com identifies a person, so it is personal data. Your customer's employees, the prospects in your CRM and the contacts on your invoices all hold the right.

Location does not save you either. GDPR can apply to a company based outside the EU when it offers services to people in the EU, which is why US teams selling into Europe end up here too. The right also has limits, which we cover later in this guide.

Are You the Controller or the Processor When a Deletion Request Arrives?

A data controller decides why and how personal data is processed, and a data processor handles it on the controller's behalf. In B2B SaaS you are usually the processor for your customers' end-user data and the controller for your own marketing, sales and billing data.

The role decides who answers. If an end user inside your customer's workspace asks you to delete their data, the request belongs to your customer, the controller. Under Article 28(3)(e), your contract must oblige you to assist the controller with data subject requests. Your job is to give them the tools, not to reply to the person yourself.

The split changes what you build. Processor duties mean admin tooling or an API that a customer's compliance team can trigger on their own. Controller duties mean a public intake path and a reply you write yourself.

There is a trap on the processor side. Article 28(3)(a) says you process personal data only on documented instructions from the controller. A vendor that starts deleting a customer's end-user records on its own initiative, without that instruction, is creating a problem for the customer and for itself. Forward the request, log it, and wait for their instruction. Confirm your role in the data processing agreement before the first request arrives, not during it.

How Long Do You Have to Respond to a GDPR Deletion Request?

You must tell the requester what action you took without undue delay and within one month of receiving the request. For complex or numerous requests you can extend by two further months, but only if you explain the delay within the first month. That is Article 12(3).

Two details trip teams up. First, the clock starts when the request arrives in any channel your staff touch, not when someone files a ticket. Second, the one month covers your response. Article 17 separately requires erasure without undue delay, so you cannot sit on a valid request for 29 days and call it compliant.

The UK regulator offers a practical trick. The ICO's right to erasure guidance notes that if your systems need a fixed number of days, a 28-day period keeps you inside a calendar month every time. A calendar month is shorter than it sounds, especially in February.

Set an internal target well below the legal limit. Our recommendation is a receipt within two business days and a finished deletion long before the final week, so a single failed third-party API call does not push you over the line.

How Do You Verify the Requester Without Making It Painful?

Ask for too little proof and you delete the wrong person's data. Ask for too much and you have blocked a legal right.

Identity verification is the step that confirms the person asking is the person the data belongs to, before you act on the request. Article 12(6) allows you to request additional information only where you have reasonable doubts, and only what is needed to confirm identity. The ICO frames the test as proportionality: what data you hold, how sensitive it is and what you use it for.

In B2B SaaS the sensible checks depend on how the request arrives:

• Request from a logged-in account. The session already proves control of the account. No extra proof needed.
• Email from the address on file. Send a confirmation link to that address before you delete anything.
• Customer admin asking about an end user. Confirm the admin role in your console, then process under the customer's instruction.
• Lawyer or third party. Ask for written authority and confirm with the person.
• Anything else. Do not request a passport scan to remove a newsletter subscriber. Collecting more ID than you hold data for is its own privacy problem.

Accept requests in whatever form they arrive. The ICO notes that a request can be made verbally or in writing, to any part of the organisation, and does not need to mention Article 17. That is UK guidance, but the practical lesson holds in the EU too. Train sales, support and customer success to recognise a request and forward it the same day. A deletion request buried in a reply to a renewal email still starts the clock.

Log every request with a case ID, timestamp, channel, requester, role (controller or processor), verification status and decision. That log is the first piece of proof you will need later.

Where Does Personal Data Actually Live in a B2B SaaS Product?

Hand an engineer one user ID and ask for every place that person's data sits. Then watch how long the silence lasts.

A data map is a living inventory of every system that stores or receives personal data, with an owner, a retention rule and a deletion method for each. Without one, every deletion request turns into an archaeology project.

Most teams remember the production database. The rest hides in places nobody reviews: error trackers that capture email addresses in stack traces, analytics tools that keep event streams per user ID, and warehouse tables where personal data has been baked into aggregates.

Free text is the hard part. Support tickets and logs contain personal data in places no schema can predict. Pattern matching catches emails and phone numbers. Classification models help with names and context, which is a good fit for the machine learning work in our custom AI development services, as long as a human reviews the edge cases.

Run a one-user trace test. Create a test account, use the product, then list every system that now holds a trace of it. If you cannot finish that list in an afternoon, a software audit of your data flows is the cheapest place to start.

What Is the Right GDPR Deletion Workflow, Step by Step?

A GDPR deletion workflow has six stages: receive and log the request, verify the requester, scope every system that holds the data, decide whether to delete, keep or refuse, run the deletion everywhere, then confirm to the requester and store proof.

Here is the runbook behind those six stages, written the way an engineer would want to run it.

• Log it. Case ID, timestamp, channel, requester and role.
• Acknowledge it. Send a short receipt that states the date the one-month clock ends.
• Verify it. Proportionate checks only, as covered earlier.
• Scope it. Resolve the person to one internal identity, then list every system from your data map that holds it.
• Decide. Check the Article 17(3) exceptions and any legal hold. Counsel signs off on anything out of the ordinary.
• Preview. Run the deletion in dry-run mode and review what it would remove before it touches production.
• Execute. Hard delete or true anonymization, cascades included, caches invalidated, outbound calls sent to third parties.
• Confirm. Tell the person what was deleted, what was kept and why, and when backups expire. Store the proof.

Automate the scope, preview and execute steps. A manual checklist works for your first five requests. By your fiftieth, somebody forgets the support desk.

Treat the deletion job like any other production code. Make each task idempotent, so a retry never double-deletes or dies halfway. Put a queue in front of third-party calls, so one failing API does not block the rest. Cover the whole thing with tests in your pipeline. If you want help wiring that into CI/CD, our DevSecOps managed security services are built for controlled, tested automation of this kind.

How Do You Delete Data From Backups, Logs, Caches and Replicas?

Delete from live systems immediately, invalidate caches and replicas in the same job, drop or scrub log partitions on schedule, and handle backups by putting the data beyond use until a fixed retention cycle overwrites it. Then tell the requester exactly that.

Backups exist to restore a past state. Editing one person out of a snapshot defeats that purpose and gets expensive fast. The EDPB's 2026 erasure report named deleting personal data in the context of backups as one of the difficulties controllers face, so you are not alone, but you do need a position you can defend.

Crypto-shredding is the practice of making encrypted data permanently unreadable by destroying the key that decrypts it. Designing key hierarchies so one key maps to one tenant or one user is architecture work, and it costs far less before launch than after. That is the kind of design covered by our data encryption services.

Logs need a different tactic. Scanning a high-volume log row by row for each request does not scale. Partition logs by week or month, keep hot retention short, and drop whole partitions on schedule. Better still, stop writing personal data into logs in the first place by scrubbing emails and tokens at the logger.

Caches and read replicas are the quiet leak. Wipe the primary, leave the cached copy, and the data is still live. Put invalidation inside the deletion job, not in a follow-up ticket.

Whatever you choose for backups, write down a hard retention window, enforce it, and state the longest gap between the request and full expiry in your reply to the person. The ICO expects you to be absolutely clear with individuals about what happens to their data in backups.

Do Sub-Processors and Third-Party Tools Have to Delete Too?

Yes. When you have disclosed personal data to recipients, Article 19 requires the controller to tell each recipient about the erasure unless that proves impossible or involves disproportionate effort. Processors must help, and sub-processors inherit the same duties by contract.

A sub-processor is a third party that a processor engages to handle personal data on behalf of the controller. Under Article 28, a processor needs the controller's authorisation to engage one, must impose the same data protection obligations on it, and remains fully liable to the controller if the sub-processor fails. A vendor that cannot get its own sub-processors to delete has a liability, not just a to-do.

The practical problem is that the list is longer than anyone expects. Every integration adds a place where one person's data can land.

Each tool has its own deletion API or request mechanism. Wire them into the workflow as outbound calls with retries, and record every response. A support agent working from memory on a Friday afternoon is not a control.

Contracts matter as much as code. Every processor needs a data processing agreement that obliges it to assist with data subject requests and to delete data on request. Without that clause you have no lever when a vendor drags its feet. Also set retention windows inside each tool ahead of time, so there is less to delete when a request arrives.

When Can You Keep Data or Refuse a Deletion Request?

You can keep data, or refuse to erase it, when Article 17(3) applies: legal obligations, legal claims, tasks in the public interest, public health, archiving and research, or freedom of expression. A refusal must be explained to the person within one month, along with their right to complain. See Article 17 and Article 12(4).

The exception SaaS teams lean on most is billing. Tax and accounting law can require you to keep invoice records. But that exception covers the financial record, not the profile wrapped around it. If your invoice table stores name, email and address inline, you are holding personal data you may have needed to erase.

The usual fix is anonymization at the billing layer: keep amounts, dates and tax fields, and replace identity fields with a non-identifying token, where your tax adviser confirms the law allows it. Which raises a better question: what counts as erasure?

The EDPB's 2026 report specifically flagged controllers relying on inefficient anonymisation techniques as an alternative to deletion. If someone can still re-identify the person by joining two tables, you have not anonymized anything. Test it the way an attacker would.

Do not refuse because a request is inconvenient. Refusing on the ground that a request is manifestly unfounded or excessive puts the burden on you to demonstrate it (Article 12(5)). Case by case, with a written reason, or not at all.

What About Customer Offboarding and Whole-Account Deletion?

In B2B, the biggest deletion request is often not a person. It is a customer who cancels and wants everything gone.

Whole-account deletion is the removal of all personal data a customer entrusted to you when the contract ends. It is not an Article 17 request, but it runs through the same pipes. Article 28(3)(g) requires the processor contract to say that, at the controller's choice, you delete or return all personal data after the services end and delete existing copies unless the law requires storage.

A sequence that works:

• Offer an export first. Customers often need their data before it disappears. Do it before the clock runs out, not after.
• Confirm authority. Check that the person asking can speak for the customer account.
• Freeze, then delete. Agree a grace period in the contract and state the exact deletion date.
• Cascade everywhere. Tenant data, files, integrations, third-party tools, and the backup expiry schedule.
• Send a deletion certificate. Scope, date, and what remains in backups until when.

Multi-tenant products add a wrinkle. One person's data can sit in several tenant partitions, so a central identity map that ties an internal user ID to every location it touches makes both individual and whole-account deletion tractable.

Put these terms in the contract and the order form, not only in the help docs. A buyer's security review will ask how deletion works, and a clear written answer shortens that review.

What Does the EDPB's 2026 Erasure Report Mean for SaaS Teams?

In 2025, 32 European data protection authorities asked 764 organisations how they handle erasure. The results landed in February 2026.

The European Data Protection Board (EDPB) is the body that coordinates how EU privacy regulators apply GDPR. On 18 February 2026 it published the results of its coordinated enforcement action on the right to erasure. Nine authorities opened or continued formal investigations, and 23 ran fact-finding exercises.

The EDPB described seven recurring challenges. Read them as a checklist for your own workflow:

• No appropriate internal procedures for handling requests.
• Too little information given to the people who ask.
• Inefficient anonymisation used instead of deletion.
• Inconsistent practices from one request to the next.
• Difficulty setting retention periods.
• Difficulty deleting personal data from backups.
• Trouble applying the balancing tests, because the right is not absolute.

Law firm Reed Smith reports that regulators including France's CNIL, Portugal's CNPD and Sweden's IMY have indicated the findings will inform inspections and supervisory planning in 2026. The EDPB's own 2026 coordinated action targets transparency and information duties, so a clear reply to the requester matters as much as a clean deletion.

One more 2026 item. The European Commission's Digital Omnibus proposal, put forward in November 2025, would amend parts of GDPR. As of October 2026 it is still in negotiation between the Council and the Parliament, and it is reported to focus on the definition of personal data, abusive access requests, information duties and AI training. Watch it. Build to the text that is in force today.

What Mistakes Make a Deletion Workflow Fail an Audit?

Most failed audits are not about a missing policy. They are about a policy the systems were never built to follow.

Regulators and enterprise buyers ask for evidence, not intentions. Infringing data subject rights falls in the higher fine tier of Article 83(5): up to €20 million or 4 percent of total worldwide annual turnover, whichever is higher. Here is what tends to go wrong.

• Soft delete only. A flag hides the row. The data still exists, and the person never stopped being identifiable.
• Forgetting caches, replicas and logs. The primary is clean. Three other copies are not.
• Treating anonymization as a magic word. If a join brings the person back, it was never anonymized.
• Unclear roles. Deleting a customer's end-user data without instruction, or ignoring a request that was yours to answer.
• Manual third-party cleanup. It works until the person who remembers goes on holiday.
• Backups with no retention limit. A three-year-old snapshot holding a deleted user's full profile is a live exposure on a shelf.
• No proof. The work was done and nobody can show it, or the proof stores the very data you deleted.
• Late or vague replies. The deletion was fine, the answer to the person was not.

Proof deserves its own design. Store enough to demonstrate what you did and nothing that rebuilds the person's profile.

Documented, repeatable controls are exactly what ISO 27001 audits reward. TAK Devs is ISO 27001 and ISO 9001 certified, and our ISO compliance services help teams build the same discipline into their own delivery.

How Do You Roll Out a Deletion Workflow in 90 Days?

You do not need a platform rebuild. You need three focused months and one accountable owner.

A 90-day rollout is a staged plan that takes a team from no deletion workflow to a tested, documented, automated one. It works because each phase produces something you can use even if the next phase slips.

Help is available at each stage. Our full range of security, compliance and engineering solutions covers the path from audit to implementation: software audit services to map data flows, data encryption services for key design, DevSecOps managed security services for pipeline automation, and ISO compliance services for the evidence trail.

One caveat. This guide is engineering guidance, not legal advice. Have your own counsel confirm how Article 17 applies to your data, contracts and jurisdictions before you finalize the rules.

GDPR Deletion Requests for B2B SaaS: Frequently Asked Questions

The questions engineering and product leaders actually ask when the first deletion request lands, answered straight.