Data controller vs processor, and why it decides your GDPR workload: Flick Fisher of Fieldfisher

The data controller vs processor distinction is the first question a company should answer about GDPR and the one most teams skip. Flick Fisher's point is that it determines the entire scope of what you have to do, and getting it wrong means either doing far too much work or the wrong work entirely.

Fisher is a European privacy specialist and a partner in Fieldfisher's privacy, security and information group. Originally from the UK, she moved to San Francisco to help establish the firm's US practice, and now advises technology-focused US clients on European privacy law. She was named a Top 40 Under 40 Data Privacy Lawyer by Global Data Review. She is also, in practice if not in title, the operations lead for the San Francisco practice.

A one year secondment that did not end

Fisher came to California on a one year secondment with a return ticket. Within six months she had met her now husband and decided to stay.

The move to Fieldfisher came through Mark Webber, now managing partner of the Silicon Valley office, who had worked with her at a previous firm and invited her to follow him.

Her timing was fortunate. She arrived to do technology transactions and privacy work in the run-up to GDPR, at a moment when privacy was usually a subsection of a technology practice rather than a specialism. A brand new law was replacing one that dated to the early 1990s, which made it a rare chance to become a specialist in an emerging field.

Her expectation at the time is worth recording, because it was wrong in an instructive way. She thought this would be a couple of pieces of legislation to master. Instead there has been an explosion of privacy regulation, in Europe and then worldwide as other countries copied the GDPR. Her description of the job now is that being a privacy lawyer is like being an acrobat, constantly adapting to new guidance.

Running a law practice like a startup

Fisher was roughly employee number four in the Silicon Valley office, which she describes as feeling very much like a startup. Seven years later the team was 13 people.

The scaling problem is a specific one. They are European privacy specialists recruiting in the United States, which makes the talent pool small, and visa logistics add friction.

They cannot solve it with remote hiring either, and the reason is their actual differentiator. Fieldfisher offers European privacy specialists in the client's time zone, and has the largest such team in the US. That requires people who can pick up the phone during a US working day, so while they are flexible about where in the country someone sits, they need them in the country.

On marketing, her answer is refreshingly plain. They did not have much marketing support, so the approach was hands on. Doing good work won more work, and they built a reputation for practical, technically literate advice. Beyond that, conference travel, webinars, and the strength of the Fieldfisher brand in privacy.

She also credits the market itself, with a joke that has some truth in it. European regulatory change created enormous demand for privacy lawyers, and she suggests the firm owes a fruit basket to Max Schrems.

Remote work in an industry built on presence

Fisher is candid about the legal profession's traditional posture, which she calls archaic on flexible working, complete with the familiar image of people afraid to leave the office.

The pandemic forced a genuine change, people dispersed, some worked while traveling, and it worked. Which disrupted the old assumptions about how a legal team has to run.

The cost she names is specific and matches what other firms report. Junior lawyers lose the hands-on time they need, the collaboration and the ability to bounce ideas around, and with it the mentoring and knowledge transfer that used to happen by proximity. Her conclusion is that there is a middle ground to find.

Their practices are modest and deliberate. Team check-ins twice a week, on Monday and Wednesday, after starting with daily huddles at the beginning of the pandemic and concluding that was too much. Encouraging office attendance and team events as people became comfortable.

The management piece she stresses is checking in individually, because circumstances vary enormously. She has a house she can work from easily; others are sharing apartments.

Her team carries an additional weight that many international teams will recognize. Everyone is working away from their home country, and some had not seen family for two years because they could not travel. The team includes Bolivian, French and Spanish colleagues, so it was never just about getting back to the UK. Her framing of the response is providing a home away from home as best they could.

What the GDPR actually is

Fisher's short version: the General Data Protection Regulation is Europe's main privacy law, binding all 27 EU member states, setting out principles you must follow when processing personal data.

The part US companies underestimate is jurisdiction. It reaches companies offering services in Europe or monitoring people in Europe, not only companies located there.

Her explanation of why it feels like the rules change weekly is the useful part. GDPR took effect in 2018, replacing a directive from the early 1990s, and arrived with real teeth in the form of fines up to 4% of global turnover.

But it is principle-based rather than prescriptive, which frustrates people who want a control checklist in the style of a security standard. Because the requirements are stated as principles, everyone depends on subsequent guidance and case law to know what compliance looks like, and that body of interpretation is only now arriving at pace.

Privacy Shield, and the case that removed it

Fisher gives the clearest short explanation of this I have read.

Privacy Shield was a self-certification scheme run by the US Department of Commerce, agreed with the European Commission. A US company that signed up and complied could lawfully receive European data for processing in the US. Thousands of companies signed up, because it was convenient.

The scheme was reviewed annually, and those reviews kept identifying the same deficiencies: it did not adequately protect European data from US government access under foreign surveillance authorities, and it did not give Europeans a real way to challenge that access.

Max Schrems, the Austrian privacy activist Fisher describes as privacy's biggest celebrity, built a case around exactly those points. Fisher's account of his motivation is that he attended lectures in the US involving Facebook and concluded that what was happening did not comply with fundamental rights in Europe.

In 2020 Europe's highest court agreed and invalidated Privacy Shield. Overnight, every company paying a certification fee lost the mechanism it relied on.

Most pivoted to Standard Contractual Clauses, a template set of contractual privacy commitments pre-approved by the European Commission that a data importer signs with a European exporter.

The complication is what the court said next. The clauses are valid, but you cannot rely on them alone. You also have to assess each transfer case by case, considering whether you are subject to foreign surveillance law and what encryption you apply, in what is called a Transfer Impact Assessment.

The practical outcome, Fisher says, is that transferring personal data to the US in unencrypted form is now very difficult to do in line with regulator expectations.

She is careful to correct a common misreading. The GDPR does not ban transfers to the US. That is not in the law. The difficulty comes from the 2020 decision and the guidance that followed, which makes processing European data in the clear, in a country without an adequacy decision, challengeable.

Why this collides with how software actually works

Michael puts the operational consequence in concrete terms, using support as the example, and Fisher confirms it.

The pressure pushes European customers of US SaaS platforms toward local providers offering entirely European support and hosting. Her objection is practical rather than legal: follow-the-sun support becomes impossible if everyone must be in Europe, and it does not reflect how software is built and supported by engineering teams around the world.

Her summary is that a focus on borders and keeping data in Europe runs counter to how technology services are delivered.

Should a startup retreat from Europe?

Michael raises what he hears from companies: that compliance has become too onerous and some are considering a strategic retreat. Fisher's answer is measured and, for most companies, reassuring.

Regulatory attention has largely landed on data exporters, meaning the European customers of US platforms, rather than the platforms themselves. And the decisions have tended to be instructions to stop using a particular service rather than large fines. Google Analytics and other tools have been the subject of these.

Her view is that the risk to your potential customers is not yet enough to justify abandoning Europe. It remains a large, lucrative market with genuine appetite, and there are still not enough European-hosted alternatives to serve it.

Her practical advice: build the basic compliance hygiene you will need, avoid unnecessary risk, and recognize that a regulator is far more likely to pursue your customers than a small US startup. Meanwhile everyone, including the largest platforms, is waiting for a political solution.

That solution is a successor to Privacy Shield. Fisher notes that even Meta has publicly framed the issue as needing a workable mechanism rather than wanting to leave Europe, and that the Commission and the Department of Commerce have both stated commitment to reaching one. Her expectation about the alternative is blunt: there is no appetite in the US to narrow its surveillance laws, so the political agreement is what everything hangs on.

How European regulators actually work together

Fisher explains a structure most operators never see.

GDPR is an omnibus regulation, applying automatically across all 27 member states without national implementation. But it contains over 50 provisions allowing local law to add specific requirements, so national nuances persist under an ostensibly uniform law.

Each national regulator can bring actions for its own data subjects. A company operating across several member states usually has a lead supervisory authority acting as its point regulator, as the Irish Data Protection Commission does for Facebook.

But the lead regulator cannot act alone. A preliminary decision goes to the other member states through the European Data Protection Board for approval, so significant outcomes are effectively collective.

The exception proves the point. The Austrian decision on Google Analytics was taken by the Austrian regulator alone, and Fisher notes other regulators subsequently hinted that it was made without regard for wider regulatory opinion and may have boxed them into a conservative position.

The other law nobody accounts for

Fisher flags something teams routinely miss because they are focused on GDPR.

The ePrivacy Directive governs marketing and tracking through cookies, and its trigger is different. It does not care whether you are collecting personal data. It cares whether you can access information stored on someone's device.

If you can, you need consent and notice, which is why cookie banners exist. And it covers any tracking mechanism, in an app, through an SDK, or via web beacons and pixels. Controller or processor, personal data or not, it applies.

Should you just build to the German standard?

Michael asks the question many operators reach for, on the theory that Germany is the strictest and clearing that bar clears all of them.

Fisher's answer is no, with an exception.

Germany has the same underlying requirements, since GDPR applies there as everywhere. The differences come from local interpretation and from appetite for enforcement, which varies considerably. Germany has 16 regulators, which she calls nuts, and a historically grounded sense of privacy as a fundamental right, which together produce a more conservative posture.

But designing to the most conservative German guidance would leave you with a badly restricted product if your business relies on data, and much of that guidance is not legally binding.

The exception is market-specific. If Germany is a key market and you are selling into a heavily regulated sector like healthcare or financial technology, you may need to design to those requirements. The same logic applies to any market where regulated industries are your target.

Controller or processor, and why it comes first

This is the part every operator should take away.

Before deciding what to build, work out which role you are playing, because the two carry very different obligations.

A processor handles data only to deliver a service to a customer, under that customer's instructions. Its obligations are comparatively narrow: agree appropriate contractual terms and keep the data secure. A processor does not have to worry about transparency or obtaining consent, because those belong to the controller. As Fisher puts it, stay in your processor lane and keep good vendor hygiene.

A controller decides how and why data is processed: the purposes, who it is shared with, how long it is kept. Controllers carry the bulk of the obligations, which include privacy policies and real engineering work to satisfy deletion and access requests.

The nuance that matters is that most companies are both. Fisher's example is the typical SaaS platform, where customer data is treated as sacrosanct and the company acts as a processor of it. But that same company collects usage data, how people click, which features they use, how long they stay on pages, often through analytics tooling. For that data it is almost certainly a controller, with a separate and longer set of obligations.

She adds one for operators specifically: on employee data, you are definitely a controller.

Where to actually look things up

Fisher's recommendations are practical. The European Data Protection Board publishes the authoritative guidance, though she warns it is not easy going if you are new to privacy.

Her more useful suggestion is the UK. Despite Brexit, the UK is subject to a near-replica of GDPR and, in her assessment, publishes some of the best and most user-friendly guidance available.

She also notes how far this has spread. Most countries now have some level of privacy law, which was not true recently. India was about to make substantial updates, China had just revised its own regime, and the pattern is similar-but-different requirements everywhere, which makes a single global program genuinely hard.

Her conclusion is the one worth holding: GDPR remains the gold standard, and a program built on it puts you in good stead, with local nuances layered on top.

Michael's addition for US-only companies is the necessary caveat. California, Colorado, Illinois and Virginia have their own laws, and the alternative to federal action is complying with fifty of them.

What she did not expect to see

Asked the standing question, Fisher points at security breach work, which is a significant part of the practice.

Her answer is about the weaponization of cybercrime following Russia's invasion of Ukraine, and the conversations that has produced with clients in recent weeks. Her practice exists partly to help companies navigate the legal obligations that attach when those risks materialize.

Michael's addendum is the practical one for any operator listening: make sure you have cyber insurance.

The 5 things I took away from this conversation

1. Settle controller or processor before anything else. This one decision sets the entire scope of your obligations, and most teams start building compliance without making it. The corollary is more useful still: you are almost certainly both, processor for customer data and controller for your own analytics.

2. Your analytics are a bigger exposure than your customer data. Companies protect customer data carefully because contracts require it. The usage data they collect for their own purposes gets far less thought, and that is exactly where controller obligations attach.

3. Do not build to the strictest interpretation by default. The instinct to design for Germany and assume you have covered everyone produces a needlessly restricted product, and much of that guidance is not binding. Build to the regulation, then add requirements where a specific regulated market demands it.

4. Regulators are pursuing your customers, not you. This reframes the risk calculation for any US company weighing a European retreat. The enforcement pattern has been directed at European data exporters and has taken the form of stop using this tool rather than large fines.

5. The ePrivacy Directive does not care whether it is personal data. If you can read something off a user's device, consent rules apply, whatever the data is and whichever role you occupy. That catches a lot of tracking that teams have filed under a GDPR analysis that does not apply.

FAQ

What is the difference between a data controller vs processor? A controller decides how and why personal data is processed, including purposes, sharing and retention, and carries the bulk of GDPR obligations. A processor only handles data to deliver a service under the controller's instructions, and its obligations are largely contractual terms plus security. Most companies are both, depending on the dataset.

Which am I for my own product analytics? Almost certainly a controller. Fisher's example is a SaaS platform that acts as a processor of customer data but collects its own usage data about clicks, features and session length. Because the company decides why that data is collected and how it is used, it is a controller of it, with a separate and longer compliance obligation.

What does GDPR compliance for US companies actually require? It starts with establishing your role for each dataset, since that sets the scope. Beyond that, expect contractual mechanisms for transfers, a transfer impact assessment where data moves to the US, security obligations, and for controllers, privacy notices plus the engineering work to handle deletion and access requests.

Is transferring data from the EU to the US illegal? No. Fisher is explicit that GDPR does not ban it and that no such prohibition exists in the law. What changed is that invalidating Privacy Shield in 2020, plus subsequent guidance, made transferring personal data in unencrypted form to a country without an adequacy decision difficult to defend to regulators.

Should we design our privacy program to German requirements? Generally no. Germany applies the same regulation with more conservative guidance and more enforcement appetite, but much of that guidance is not legally binding and designing to it would unnecessarily restrict a data-driven product. The exception is if Germany is a key market and you sell into a heavily regulated sector such as healthcare or fintech.

Also mentioned

• Fieldfisher and its Silicon Valley privacy practice, plus its privacy blog and webinar series
• Max Schrems and noyb, whose litigation invalidated Privacy Shield and continues against large platforms
• Standard Contractual Clauses and Transfer Impact Assessments
• The European Data Protection Board and the UK Information Commissioner's Office, which Fisher rates for readable guidance
• The ePrivacy Directive, the source of cookie consent obligations regardless of personal data
• The Irish Data Protection Commission, Facebook's lead supervisory authority
• Flick Fisher on LinkedIn, where she posts upcoming webinars

Listen to the full episode

Flick Fisher on Between Two COO's

Between Two COO's is hosted by Michael Koenig. Subscribe on Apple Podcasts, Spotify, or wherever you listen.