Does GDPR apply to my company if we're not based in Europe?

If you handle data belonging to people in Europe, GDPR applies regardless of where your company is based. The law is about whose data it is, not where you operate from.

What's the actual risk if we can't fully honor a deletion request?

Beyond the legal exposure, it's a trust problem. If a customer or patient finds out their data wasn't actually deleted everywhere it existed, that damages the relationship in a way that's hard to repair, separate from any fine or penalty.

Why does centralizing data help with compliance?

Because deletion, access control, and audit requirements only need to happen in one place instead of everywhere data got copied. Without a central source, every export and every connected tool is a place a deletion request can quietly fail.

Is this a legal problem or a data engineering problem?

Both, but the part that actually fails in practice is usually the data engineering side. Knowing the law is step one. Having systems that can act on it, especially deletion, is what most teams are missing.

What GDPR and HIPAA Actually Require From Your Data Pipeline

Quick answer

If you handle European data, GDPR applies to you. If you're in health tech, HIPAA applies to you. Most teams know that in theory but haven't actually checked whether their systems comply, and the place this shows up first is a deletion request. A customer or patient asks to be forgotten, you delete it from the database, and you assume you're done. But that same data is sitting in spreadsheets, exports, and other tools that never got touched. That's the actual compliance gap, and it's a data engineering problem before it's a legal one.

Key takeaways

Compliance isn't just knowing the law exists, it's whether your systems can act on it, especially deletion requests.
Deleting from your main database isn't enough if the same data lives in spreadsheets, exports, and other connected tools.
Centralizing data through one warehouse, with every BI and analytics tool pointed at it, makes deletion a single action instead of a chase across every place data got copied.
Non-compliance isn't only about fines. It's also about the trust you lose once people find out their data wasn't actually deleted.

What's actually happening

This is something we see overlooked constantly. Teams have no idea, or only a vague idea, that they need to comply with these laws in the first place. If you handle European data, that's GDPR. If you're health tech, that's HIPAA. And it's not enough for one person in the company to know this. Everyone who touches that data needs to know how they're supposed to handle it.

The clearest example is the right to be forgotten. A customer or a patient requests their data be deleted. That's their right under both laws. The team deletes it from the CRM, deletes it from the main database, and considers it done. Meanwhile, that same data sits in Excel sheets, in exports someone pulled last quarter, in whatever tool a team member connected without thinking about it. Nobody's tracking those copies, so nobody deletes them. That's not a data breach exactly, but it is a compliance failure, and it's the kind that's genuinely hard to catch until someone asks the wrong question at the wrong time.

Why deletion requests are the hard part

People will always want data. If there's no proper, centralized place to self-serve it, they download it and use whatever tool they found or someone recommended, usually without checking whether that tool is actually safe for sensitive data. That's the first hazard.

The second is the deletion problem itself. Under these laws, a person has the right to be forgotten. If you tell them it's done, but their data is still sitting in someone's spreadsheet or an old export, that's a compliance issue even if nobody meant for it to happen. It just means nobody had visibility into where all the copies were.

And the third hazard compounds both of the first two: if the tool someone downloaded that data into isn't secure, you've now increased your actual risk of a real data breach. These laws come with obligations, windows of time to notify people if their data is exposed, and once that trust is broken, it's broken. That's really the core reason data engineering matters for compliance. It's not paperwork, it's making sure a deletion request actually reaches every place the data exists. This is the same siloed-data problem we cover in signs your company's data is a mess.

From the team

Not sure your systems could actually honor a deletion request?

A fractional data engineer centralizes your data and builds the deletion mechanism in from the start, so a request reaches every place the data lives.

See how fractional works →

How to tell if you have a gap

You've had a deletion request and you're not fully sure every copy of that person's data actually got removed.
People in your company can export data into their own spreadsheets or tools without anyone tracking where it went.
You don't have a documented answer to which law applies to which data you hold.
Your BI or analytics tools are connected to raw exports rather than one central source.

If any of these sound familiar, the gap probably isn't intent. It's that nobody built the system to make compliance possible.

What the fix looks like

Centralize the data. Route everything through one data warehouse instead of letting every team pull their own exports. When deletion has to happen, it happens in one place instead of a dozen. See replacing spreadsheets with a data warehouse for what that looks like in practice.
Connect BI and analytics tools to that single source, not to raw exports. This alone removes most of the "extra copies nobody tracks" problem. We cover this in how to consolidate data from multiple tools.
Document what applies to you. Which laws, which data, which countries you operate in. This needs to be something your team can actually reference, not something only one person remembers.
Build the deletion mechanism into the system itself, so a request triggers removal everywhere the data lives, not just the one place someone thinks to check.
Train the team, not just the people who set up the systems, on how sensitive data should be handled day to day.

This is what we build

This is part of what we walk through with every client before we build anything: understanding their data, where they actually do business, which laws apply, and making sure the system we build has proper deletion mechanisms from the start, the same documentation-first approach we cover in how data engineering supports a growing company. We work with health tech companies, among others, so HIPAA compliance isn't an afterthought for us, it's built into how we architect the pipeline. If you're not sure your systems could actually honor a deletion request today, see how we build your data foundation.