Your Customer Didn't Churn. Your Champion Did: Rebuilding Account Coverage Under GDPR

On this page

1. Your CRM knows the account. It doesn't always know the people.
2. When should you actually enrich an existing customer?
3. Renewal is not prospecting
4. Yes, GDPR still applies. Your contract isn't the basis.
5. Legitimate interest, in the language your team speaks
6. Three obligations the relationship doesn't waive
7. From one-off lookups to continuous coverage
8. What changes when an agent does it
9. The one-page policy
10. Bottom line

You have €500,000 of ARR renewing this quarter. On three of those accounts there is no active economic buyer in the CRM. Two champions have changed jobs since the last renewal. Nobody on your team knows the VP who now controls the budget.

That isn't a CRM hygiene problem. It's renewal risk, created months before anyone noticed.

The obvious response is to find the right people inside those accounts and rebuild coverage. In Europe that raises a second question, usually in a Slack thread between Revenue Operations (RevOps), Customer Success, and whoever is nervous about GDPR that week:

"Wait, do we need their consent to do that? They never opted in."

The instinct that follows is one of two wrong answers: "we're fine, they're already our customer, the contract covers it," or "we'd better get consent first." Guess one way and you invite a complaint. Guess the other and you freeze a legitimate customer-success motion, which is one of the quieter ways a renewal goes sideways. There is a clean answer, and it isn't either of them.

This is not legal advice. It is general best-practice guidance from a go-to-market and RevOps perspective, not a substitute for a data-protection lawyer who knows your facts and jurisdiction. Use it to have a smarter conversation with your counsel.

Your CRM knows the account. It doesn't always know the people.#

Renewal risk rarely announces itself as renewal risk. It shows up as a relationship map that went stale while the contract stayed current. The company still pays, the product still runs, and the people you knew moved on without telling you.

Teams that manage this well think in coverage rather than contacts. A covered account has a named human behind each role that matters:

• the day-to-day champion who actually uses the product
• the platform or admin owner who runs it
• the economic buyer who signs
• the executive sponsor who cares whether it works
• the procurement or legal contact who handles paperwork
• any technical stakeholder your integration depends on

You don't need all six on every account. You do need to know which ones you're missing where it matters, and to notice when one disappears.

Coverage decays through ordinary events. A champion changes jobs. Email to a known contact starts bouncing. A stakeholder goes quiet for 90 days. A new executive joins. Usage shifts to another department, which license utilization broken down by team shows you long before a human mentions it. The renewal moves inside 180 days and nobody can name who signs.

Those signals already sit in systems you own: CRM activity, bounce data, product usage, support history. Coverage is a health metric in the same sense a customer health score is, and the one almost nobody computes.

When should you actually enrich an existing customer?#

Not on a schedule, and not in bulk. Enrichment should be triggered by a commercial condition you can name.

Commercially, this turns enrichment into a prioritized queue instead of a bulk job that produces records nobody calls. Legally, a trigger list is the difference between "we enriched because we could" and "we enriched because this account met a condition we defined in advance." That's the necessity argument, written down before anyone asks for it.

Renewal is not prospecting#

Before any legal analysis, answer one question: why are you contacting this person? Four positions, strongest to weakest.

1. Service, adoption, renewal, continuity. Contact about a product the customer already runs and pays for. Strongest position, and arguably not advertising at all.
2. Expansion tied to their existing use case. More seats, an adjacent module for the same team. More nuanced, usually still defensible.
3. Unrelated cross-sell. A different product for a different buyer. This looks like marketing, so treat it as marketing.
4. Cold acquisition of unrelated people. A different motion entirely. Nothing here carries it.

Know which one you're running before you enrich, and don't let a soft upsell ride along inside an operational contact and contaminate it. Position 1 is also a different motion from the net-new-lead qualification a marketing-to-sales handover governs: you're maintaining an account you already won, not sourcing a lead.

Yes, GDPR still applies. Your contract isn't the basis.#

GDPR protects natural persons, not companies. A work address like jane.smith@customer.com is Jane's personal data. It stays her personal data even though it sits on your paying customer's domain, and even though Jane is just "the admin." It identifies a living individual, so it's in scope.

This is why "they're already our customer" collapses as a legal basis. Your contract is with the company; the new contact isn't a party to it. Article 6(1)(b) of the GDPR covers the "performance of a contract" basis, and it only reaches processing necessary to perform a contract the person themselves signed. Acquiring a new person's details isn't performing the existing contract. It's a new processing activity, about a new individual, that you chose to undertake. The stakes aren't theoretical either: European authorities issued €1.2 billion in GDPR fines in 2025 alone.

So the customer relationship isn't the lawful basis. It's what makes a different basis strong.

Legitimate interest, in the language your team speaks#

The correct basis is legitimate interests under Article 6(1)(f) GDPR: processing "necessary for the purposes of the legitimate interests pursued by the controller … except where such interests are overridden by the … rights and freedoms of the data subject."

Consent is the wrong tool here. You can't get it before first contact, because asking Jane means contacting Jane using the very data you're trying to justify holding. It's circular. It's also revocable at any time, and an operational motion built on a basis the person can switch off at will is fragile by design.

The regulation practically describes your scenario. Recital 47 says a legitimate interest "could exist for example where there is a relevant and appropriate relationship between the data subject and the controller in situations such as where the data subject is a client." The UK's Information Commissioner's Office gives the same example, citing a legitimate interest in "marketing your products to existing customers."

The three-part test, answered by a revenue leader#

Legitimate interest isn't a label you apply and move on. It's a basis you document, in a Legitimate Interests Assessment (LIA). The three tests come from the European Data Protection Board's Guidelines 01/2024 on Article 6(1)(f), still draft text pending adoption, though the three-part structure itself is settled law. Here is what they sound like when a sales leader answers them rather than a lawyer.

Why are we doing this? "We have a €120,000 customer renewing in 120 days and their original champion has left." That's account management, not a fishing expedition. Purpose test passed.

Do we actually need the data? "We need the name, role, and business email of the current platform owner." A generic procurement@ inbox can't manage an account: nobody is accountable, and nothing carries over when the staff behind it change. You need an identified human owner, the same job-title-and-seniority signal you'd use to route the account internally. That's necessity, not convenience.

Would this person expect it? "They run our software at a company that pays us for it. Contact from the vendor about that service is unsurprising."

Now the same account, a different sentence: "We found the CFO's private mobile number and want an account executive to pitch a product they don't have." Same customer, same contract, and the balance has flipped. The relationship didn't decide the outcome. The purpose and the data did.

Write it down once per purpose, not once per contact. A one-page LIA is the difference between "we thought about this, and here's our reasoning" and "we didn't." Regulators treat those very differently: France's CNIL recorded 331 corrective measures in 2024, including 87 penalties totaling more than €55 million.

Three obligations the relationship doesn't waive#

Minimize what you collect. Business role, business email, company, and stop there. The fastest way to destroy the balancing test is buying private addresses and personal mobile numbers from a broker. In May 2025 France's CNIL fined a marketing firm €900,000 for prospecting with broker-sourced data whose origin its supplier couldn't prove. That case turned on invalid consent rather than a failed balancing test, but the lesson transfers: unverifiable provenance is a liability under any basis.

Tell them (Article 14). This is the one teams forget entirely. When you obtain personal data from a source other than the person, whether an enrichment tool, a broker, or LinkedIn, Article 14 GDPR requires you to inform them: your identity, the data, the source, the purpose and basis, the retention period, their rights. It's due within one month, or at first contact if you're using the data to reach them. A privacy-notice link plus one honest line in the first email discharges most of it.

Honor objections (Article 21). Under Article 21 GDPR the person can object to processing based on legitimate interest, and for direct marketing that objection is absolute. Operationally that means a permanent suppression list, checked on every enrichment run and every sequence rather than per campaign. Someone who says stop and reappears next quarter because your tool re-found them is a breach waiting to be reported.

Finally, two rules sit outside GDPR entirely. National ePrivacy law, such as Germany's UWG §7, governs advertising email specifically, with fines up to €100,000 under §20. And a California contact falls under CCPA/CPRA, not GDPR, while the EU's own Data Act is a separate regulation again. Both are covered in the FAQ below.

From one-off lookups to continuous coverage#

Here's how this usually runs today. A CSM notices the champion left and asks the account executive. The AE searches LinkedIn, pastes a contact into the CRM, then asks Legal in Slack whether that was allowed. Nobody is sure. Two weeks later another AE does the same thing and gets a different answer.

The governed version has the same steps, with the decisions moved out of individual heads:

1. Coverage is measured continuously rather than remembered.
2. A defined trigger, not a hunch, decides that an account qualifies.
3. Only approved fields are enriched: business role, business email, company.
4. Proposed contacts go to a human wherever approval is required.
5. The source, the trigger, and the action are recorded against the account.
6. Suppression and objection rules are enforced on every run.

None of that is new law. It's the same LIA, written once and enforced by a system rather than re-argued per account.

What changes when an agent does it#

The 2026 version of this question isn't "can an account executive look someone up on LinkedIn." It's "can an agent maintain stakeholder maps across five thousand accounts, continuously."

The legal principles don't change with scale. The governance does. At ten strategic accounts a quarter, tribal knowledge holds. At five thousand running continuously, every question the LIA answers has to be encoded where a machine can read it:

• What triggers enrichment, and did this account actually meet it?
• Which fields may be collected, and from which sources?
• Which actions need human approval before they go out?
• How are objections remembered across runs, tools, and vendors?
• Can you explain, six months later, why a specific contact was added?

That last one is the hard part, and it's infrastructure more than policy. An agent can only apply a rule if the rule and the account context exist as structured data. It's the same problem as structuring data for AI agents generally: an agent improvising on raw CRM exports produces answers you can't defend. That's the part we work on at RevOS. The coverage gap, the trigger that justified the enrichment, and the suppression state have to live in one queryable model before anyone lets an agent act on them unattended.

The one-page policy#

Before enriching a new contact inside a customer account, you should be able to tick every box:

• A named commercial trigger fired: champion departure, renewal window, missing economic buyer, ownership change, or expansion signal.
• The relationship with the contact's employer is genuine and current: signed, paid, live.
• The purpose is service, renewal, or account management. If it's cross-sell, you've flagged it as the weaker case.
• You're relying on legitimate interest (Art. 6(1)(f)) rather than consent, and you know why.
• A written, dated LIA is on file covering purpose, necessity, and balancing.
• The data is minimized to business role, business email, and company. No private mobiles, no broker-sourced personal addresses.
• An Art. 14 notice goes out at first contact or within one month, and a permanent suppression list is honored on every run (Art. 21).
• You've applied the right regime for where the contact actually is, and checked the local marketing law.

Bottom line#

The bigger mistake isn't enrichment. It's letting your revenue organization discover a broken relationship only once the renewal is already at risk.

Champions leave, decision-makers move, product ownership shifts between teams, and none of it shows up in the contract. A modern revenue operation detects those changes continuously, judges whether they matter commercially, and rebuilds coverage before anyone has to go looking in a panic.

GDPR doesn't prevent that. It sets the guardrails: legitimate interest as the basis, business-role data only, a written assessment, an Article 14 notice, and a suppression list you honor. Get those right and this stops being a Slack argument and becomes a process you run at scale. As more of the work moves from people to agents, those guardrails have to live in the operating system rather than in a thread somebody has to remember to search.

Frequently asked questions

Is data enrichment GDPR compliant?

It can be, but it depends entirely on what you enrich and why. Enriching a contact inside an account you already have a genuine, paid commercial relationship with, for account management or renewal purposes and limited to business-role data, is defensible under GDPR's legitimate interest basis (Article 6(1)(f)). Buying private mobile numbers or personal emails from a data broker for cold prospecting is a much weaker case and often fails the balancing test. The lawful basis, the purpose, and the data you actually collect all matter more than the fact that 'enrichment' happened.

Can we use legitimate interest instead of consent for an existing customer?

Yes, and for this specific scenario it's the better basis, not just an alternative. Consent is circular here, because you'd need to contact the person to ask for it, and it's revocable at will. GDPR's Recital 47 explicitly names an existing client relationship as an example of where a legitimate interest can exist. Legitimate interest is the stronger basis, but it still requires you to run a Legitimate Interests Assessment, minimize the data you collect, send an Article 14 transparency notice, and honor the right to object.

When is a legitimate interest assessment required?

Whenever you rely on Article 6(1)(f) as your lawful basis, you should document a Legitimate Interests Assessment (LIA) before you start processing. That document is how you demonstrate accountability under GDPR's Article 5(2). An LIA has three parts: is the interest legitimate (the purpose test), is the processing actually necessary to achieve it (the necessity test), and do your interests override the person's rights and reasonable expectations (the balancing test). Write it down once per processing purpose, not once per individual.

What is the three-part test for legitimate interest?

The three-part test is described in the European Data Protection Board's draft Guidelines 01/2024 on Article 6(1)(f), which are still pending final adoption. It asks: (1) Purpose: is there a genuine, legitimate interest behind the processing? (2) Necessity: is this processing actually necessary to achieve that purpose, or could you achieve it another way? (3) Balancing: do your interests override the individual's rights, freedoms, and reasonable expectations? All three have to pass. Failing the necessity test (for example, collecting more data than you need) or the balancing test (for example, the person would be surprised or harmed) means legitimate interest isn't available, regardless of how legitimate your purpose is.

Does GDPR cover marketing email, or does something else apply?

Both, and they are separate obligations. GDPR governs whether you may hold and process the person's data at all (the lawful basis). National ePrivacy law governs whether you may send them electronic marketing. Germany's Act Against Unfair Competition, UWG §7, is the strict example: unsolicited advertising email to someone who did not give you their address is heavily restricted, with fines up to €100,000 under §20 UWG, on top of any GDPR exposure. The trigger word matters, though. It is advertising (Werbung), and genuine operational contact about a product the customer already runs is generally not advertising, so these rules largely do not reach it. This is jurisdiction-specific, and the existing-customer exceptions that do exist, such as UWG §7(3), are narrow: similar products only, plus an opt-out on every message.

Does this apply to contacts outside the EU?

No. Lawful-basis analysis is a GDPR concept and it applies to people located in the EU. A California resident falls under CCPA/CPRA instead, an opt-out regime with a different structure, and a growing number of other US states have their own similarly shaped laws while plenty still have none. A problem with a US contact is a real compliance question, just not a GDPR one, so do not file it as a 'GDPR violation.' For a repeatable global process, build to the GDPR standard and apply the same hygiene everywhere, while still respecting each regime's own mechanics: opt-out signals for US contacts, ePrivacy rules per country.

What is the difference between legitimate interest and consent?

Consent means the person actively opted in, and they can withdraw it at any time, which resets your basis to zero. Legitimate interest means you, the company, have a genuine reason to process the data that doesn't require the person's prior opt-in. You still have to document why (the LIA), tell them how you got their data (Article 14), and stop immediately if they object (Article 21). Consent puts the decision in the person's hands upfront; legitimate interest puts the burden of justification on you, on an ongoing basis. Note that this is distinct from the 'legitimate interest' option you sometimes see in a cookie-consent banner. That is an ePrivacy/cookie-law mechanism for tracking technologies, not the GDPR Article 6(1)(f) lawful basis this article is about.

Read more about revenue operations, growth strategies, and metrics in our blog and follow us on LinkedIn and Youtube.

All articles