Skip Navigation or Skip to Content
Search icon
Light mode icon
Dark mode icon

0%

The Same Data That Powers Your Lead Generation Can Power a Scam: Data Governance for FinTech Growth Teams

The Same Data That Powers Your Lead Generation Can Power a Scam: Data Governance for FinTech Growth Teams

Data governance is one of those topics that sounds abstract until something makes it suddenly, uncomfortably concrete. For us, that something arrived in an inbox on an otherwise unremarkable Tuesday morning.

A message from "Sheila"

About week ago, an email landed in my inbox. The sender was none other than our CEO Sheila Mitham, or so they claimed.

The message was three lines long: a generic "Hi anita," a request to send a direct message to a private WhatsApp number "regarding the tasks that need to be completed," and a formal sign-off.

The platform flagged it with a screaming red banner telling me “this message might be dangerous.”

The irony is that the attacker got the name and the job title exactly right, but everything around them went haywire:

  • The sender address was a personal Gmail account, not a company domain.
  • The greeting wasn't capitalised.
  • The ask itself was structurally odd for a real CEO.
  • Asking to move the conversation off company emails (at least on my end), onto an unverified private number

Nobody at Evara is ever going to message a stranger's WhatsApp number on the strength of three sentences from a free email account signed with the right name. That's not the story worth telling.

Phishing vs Data Governance

Getting the CEO's name and title correct cost the attacker nothing. Sheila Mitham's name and role at Evara are a matter of public record - searchable for free on the UK's Companies House register director names from public view. This was no breach of Evara platforms, and none of our data protection practices failed. In the world of manual research, finding this information would have taken 30 seconds. In the world of AI and MCPs, it probably takes an hour to find thousands of companies and their CEOs.

What we should look at is not phishing attempts, but data governance. It's the same story whether the attempt lands with three lines from a Gmail account or with a meticulously personalised wire-transfer request that clears a bank's own fraud checks.

While banks would tell you to watch out for email handles and account names, for spelling mistakes and false information, data governance experts will tell you to be aware of what you’re sharing. Not how the scammers are contacting you.

The Regulatory Backdrop

Financial services firms operating in the EU are now bound by the Digital Operational Resilience Act (DORA), which treats ICT and data-handling failures as operational risk, not just IT risk, with penalties running up to 2% of annual global turnover. UK and EU firms already carry GDPR obligations that apply just as much to a CRM record as to a bank account. None of this is written with marketing or growth teams in mind, but none of it exempts them either.

What Growth Teams Should Worry About

Here's what makes this interesting for anyone running a growth function, not just a security team: the tools that made Sheila's name discoverable in thirty seconds are the same tools growth teams use every day. ZoomInfo, Sales Navigator, enrichment tools, the entire category of software built to find a prospect's name, title, and company in seconds exists because data is public, structured, and cheap to pull. We know this because it's our job. We build these pipelines for clients.

That's not an argument against enrichment. It's an argument for treating the data your own growth stack touches with the same discipline a bank treats its fraud systems. The asymmetry runs both ways. If Evara can pull a CEO's name and title from Companies House in seconds to build an ICP, so can anyone building a scam. The difference is what happens to the data once it's inside your systems, not the tools themselves.

What we need to consider when working with data is:

  • Where does that enriched data land, and who has access to it once it's there?
  • Is a prospect record still live in your CRM six months after the deal died, or the contact left the company?
  • Does your lead-scoring model expose more about a contact than the score itself needs to?
  • If a vendor's API key leaked tomorrow, would you know exactly what “escaped” with it?

All of these are not phishing questions but the same governance questions banks have been forced to answer under DORA and GDPR. We just applied them to the growth systems most fintechs still treat as Marketing's problem, not Compliance's.

What Makes a Tool Safe to Use in 2026/2027?

Here's the problem with "is this tool safe" as a question: most people answer it by checking whether the vendor has a badge on their homepage. That's not nothing, but it's not the whole answer either. Some of these badges mean a lot. Some mean almost nothing without the report behind them. It's worth knowing the difference before you plug another tool into your stack.

Certifications of Value to Finserv/Fintech Companies

Certification

Description

SOC 2 Type II

Not a certification, technically. It's an attestation report from a licensed auditor, built around five criteria: security, availability, processing integrity, confidentiality, and privacy. Type II matters more than Type I, because Type I checks whether controls exist on one day; Type II checks whether they actually held up over a period of months. The report itself is confidential; you have to request it and sign an NDA to read it.

ISO/IEC 27001

A real, publicly verifiable certification, issued by an accredited body, covering the vendor's entire information security management system rather than a single product. Recognised in over 160 countries, which is why it tends to matter more for vendors selling into the EU or UK than SOC 2 does on its own.

ISO/IEC 42001

It's the first international standard for AI management systems specifically, published in December 2023 and now showing up in roughly 40% of enterprise AI vendor RFPs in the EU. If a tool uses AI to enrich, score, or act on your data, this is the certification that says someone is actually governing that AI system, not just the infrastructure underneath it. Most vendors don't have it yet. That's useful information too.

A signed Data Processing Agreement (DPA)

A DPA sets out who's the controller, who's the processor, what happens to sub-processors, and what happens to your data when the contract ends.

The Tools We Use

  • Clay holds SOC 2 Type II, ISO 27001:2022 and ISO 42001:2023, both listed on their Trust Center. Clay's Enterprise tier also offers a "Headless CRM" mode, where nothing gets stored on Clay's side at all and you bring your own API keys, a genuinely useful control if you want the enrichment without the data residency question. All reports and certificates are available upon request.
  • HubSpot publishes a public SOC 3 summary, and maintains a confidential SOC 2 Type II report available on request. It signs DPAs as standard and gives you the tools to run GDPR compliance but the tools existing doesn't mean you're compliant. You still have to configure them properly. HubSpot is the processor; while the business owner is the controller.

Evara’s Certifications

Evara holds ISO 9001 and ISO 27001 certification, the two internationally recognised standards our fintech and financial services clients most often ask about when evaluating a growth partner who will handle sensitive customer and prospect data.

ISO 9001

ISO 9001 is the international standard for quality management systems. Certification means Evara's delivery processes, from ICP development through lead scoring and smart lead generation, are documented, consistently applied, and independently audited on an ongoing basis, rather than depending on any one person's way of working. For clients, that translates into predictable delivery quality and a paper trail for how decisions and outputs are reached, not just what they are.

ISO 27001

ISO 27001 is the international standard for information security management systems (ISMS), covering how an organisation identifies, manages, and reduces risk to the data it handles. Certification means Evara's approach to client and prospect data, access controls, data handling procedures, incident response, and ongoing risk assessment, has been independently audited against a recognised global standard, not just described in an internal policy document. This sits at the centre of how we build lead scoring models, ICP frameworks, and intent-signal pipelines for clients operating under GDPR, DORA, and equivalent regulatory regimes.

What’s New for 2026 and 2027: AI agents and MCP

If a tool now lets an AI agent act on your behalf (e.g.: querying your CRM, enriching a list, pulling records through an MCP connection) the old SaaS security checklist isn't enough on its own. The Model Context Protocol's own security specification, formalised in the November 2025 spec, sets out what a safe implementation actually requires:

  • OAuth 2.1 with PKCE for any remote MCP server; the older, looser OAuth 2.0 implicit flow is no longer considered acceptable.
  • No token passthrough. A server should never simply forward a token it received to a downstream system. Explicitly called out as an anti-pattern in the MCP spec itself, because a token issued for one purpose can end up reaching systems it was never meant to touch.
  • No plaintext HTTP endpoints. A meaningful share of MCP servers assessed in 2026 still run on plaintext HTTP, exposing tokens and session data to anyone maliciously intercepting the connection.
  • Scoped, least-privilege access, not a single broad credential the AI agent can use for anything. An agent that's supposed to pull a weekly report shouldn't be technically capable of dumping your entire customer table.

None of this is theoretical caution. The first malicious MCP package was found in the wild in 2025, stealthily exfiltrating email data via BCC for two weeks before anyone noticed. If a vendor can't tell you plainly how their AI features handle authorization, that's the question to ask before the badge.

How to Handle Data Discussions with Your Partners

So, what do certificates mean? A certificate tells you someone audited the vendor once. A DPA tells you what happens to your data contractually. Neither tells you whether the specific AI feature you're about to switch on was built with the same care as the rest of the platform. Ask about that part directly.

What This Means for Evara's Clients

We build lead-scoring models, ICP frameworks, and intent-signal pipelines for financial services companies. Every one of those systems touches the same category of data that made Sheila's email possible – names, titles, companies, contact details, often enriched from the exact same public sources an attacker would use.

The governance question isn't whether to use that data. It's whether the systems built around it can withstand the same scrutiny a bank applies to its own fraud infrastructure: documented access, clear retention rules, and an audit trail that survives contact with a regulator.

That's the standard we build to. It's worth asking whether your current stack does too.

WRITTEN BY

Related Thinking

More on this topic

GET IN TOUCH

Ready to apply to your growth?

Every growth challenge is different. Tell us where you are today and we will share a clear perspective on what is possible. No obligation. Just a focused conversation with someone who understands Financial Services.

No obligation. Response within 1 business day.