Financial Services: Your CRM Data Walks Out Undetected

Financial services firms have spent three years preparing for operational resilience compliance. Important business services identified. Impact tolerances set. Mapping completed. Testing scenarios documented.

But there’s a gap in every framework: demonstrating you can remain within impact tolerances requires confidence about what data is actually at risk during incidents.

Without that confidence, maintaining important business services becomes impossible. You shut down, not because systems are compromised, but because you can’t prove that client data isn’t being stolen.

That’s not operational resilience. That’s operational panic with documentation.

I’ve spent 40 years in cybersecurity. The FCA operational resilience policy is necessary. Firms do need this framework. But compliance documents don’t prevent data theft during incidents. They document what you should do. They don’t give you the capability to actually do it.

The capability gap is in application data theft prevention. And most firms don’t know they have it until they’re breaching impact tolerances during incidents.

Your most valuable data doesn’t live in email anymore. It lives in CRM systems.

Client portfolios in Salesforce. Investment strategies in Dynamics. Decades of relationship intelligence in wealth management platforms. Financial planning data in desktop applications. Fund administration records in custom systems.

This is where your competitive advantage lives. This is what regulators expect you to protect. This is what clients trust you to safeguard.

And it’s completely invisible to DLP.

DLP monitors email and web traffic. Brilliant for preventing accidental data loss, via a sales rep emailing a client list to personal Gmail, or an analyst uploading a portfolio summary to a public cloud. DLP catches these before they become ICO reportable breaches.

But deliberate data theft during active security incidents? That’s a different problem entirely.

Attackers don’t exfiltrate CRM data via email. They target application-to-application data flows that traditional security never sees: desktop CRM clients, API integrations, custom application connections, and direct vendor synchronisation.

Your security stack operates in silos. DLP at the email/web layer. EDR on endpoints. Network firewall at the IP layer. None correlates which application process is sending what data to which destination.

When incidents occur, you discover this gap the hard way: no visibility into whether CRM data was exfiltrated. No confidence in maintaining client-facing services. No choice but to shut down while forensics teams investigate.

That violates impact tolerances. That fails operational resilience requirements.

Let’s look at how this happens in financial services environments.

Salesforce desktop client: Syncs client portfolio data to Salesforce infrastructure. Legitimate business operation. Your network firewall sees “HTTPS traffic to Salesforce IP range”, so it permits it.

But what if DNS has been poisoned and that Salesforce client is actually connecting to the attacker infrastructure masquerading as Salesforce? Your firewall still sees “traffic to what DNS says is Salesforce.” DLP doesn’t monitor desktop application traffic. The data walks out.

Excel portfolio exports: Analyst downloads client portfolio from CRM, opens in Excel for modelling. Saves to the local drive. Later that week, malware exfiltrates it via a covert channel. DLP never saw the Excel file because it only monitors email and web uploads.

API data flows: Custom integration between your CRM and analytics platform. Legitimate business application transmitting client intelligence. Network firewall sees “traffic between known business applications”, so it permits it. But attackers compromise the analytics platform specifically to harvest CRM data. Your firewall can’t distinguish legitimate from malicious because both use the same application channels.

Desktop CRM clients: Microsoft Dynamics running locally, transmitting client data to Microsoft infrastructure. Or to an attacker infrastructure masquerading as Microsoft via DNS spoofing. Your security stack trusts DNS responses. Attackers don’t.

This isn’t theoretical. This is how £6.08 million average breach costs happen in financial services – 22% higher than the cross-industry average. This is why ransomware incidents doubled in H1 2023. This is why 80% of Bank of England survey participants cite cyber-attacks as top-five risks.

The FCA’s PS21/3 policy is outcomes-based: minimise the impact of operational disruptions for consumers, firms, and markets.

Key requirements:

• • Identify important business services
  • Set impact tolerances (maximum tolerable disruption)
  • Map dependencies for each service
  • Test severe but plausible scenarios
  • Remain within impact tolerances by 31 March 2025

For financial services, important business services typically include:

• • Client portfolio management
  • Investment execution
  • Wealth management advice delivery
  • Payment processing
  • Customer relationship management

Notice what’s common across all these? Client data in CRM systems.

If you can’t maintain these services during incidents, you breach impact tolerances. FCA expects firms to demonstrate resilience – i.e. operational capability during disruptions, rather than “perfect prevention”.

But here’s the operational reality: maintaining client-facing services during active security incidents requires confidence that client data isn’t being stolen.

Without that confidence, every important business service shuts down immediately. Not because they’re compromised, but because you can’t prove they’re safe.

December 2024: FCA and PRA published a new consultation on operational incident reporting. Key focus: demonstrating resilience during incidents, not just documenting frameworks.

The operational question regulators will ask: “Why did you breach impact tolerances? What prevented you from maintaining important business services?”

Most firms will answer: “We shut down because we couldn’t confirm that client data wasn’t being stolen.”

That’s a compliance failure. Not because you got breached – FCA acknowledges breaches happen. But your security architecture doesn’t give you the capability to respond strategically during incidents.

Framework documentation proves you understand requirements. Application data protection proves you can meet them during actual incidents.

One gets you through audits. The other keeps you operational when competitors are offline.

DLP protects email and web data, such as client lists accidentally emailed or portfolio summaries accidentally uploaded. That’s 20% of your data risk, and DLP handles it well.

The other 80% of data is in desktop applications: CRM systems, portfolio management tools, wealth management platforms, and financial planning software. Application-to-application data flows are invisible to traditional security.

When attackers breach perimeter security, this is what they target. Not your email archive. Rather, your CRM data. Client portfolios in Salesforce. Wealth management intelligence in Dynamics. Decades of client relationship data in custom systems.

Traditional security can’t see these flows. Not because it’s broken, but because it was designed for different threats: perimeter defence (firewalls), device protection (EDR), accidental data loss (DLP).

None were designed to prevent deliberate application data theft during active security incidents.

This gap is why 58% of financial firms suffered supply chain attacks. Why ransomware incidents doubled. Why average breach costs hit £6.08 million. Why firms breach FCA impact tolerances during incidents.

I founded ZORB to fill this gap. Not as a DLP replacement, as you need that for email/web data. But as the missing piece that protects application data during incidents.

We monitor application data flows that traditional security doesn’t see. Every outbound transmission from Word, Excel, Salesforce, Dynamics, and custom applications is validated in real-time against three criteria:

1. 1. Source verification: Is this application authorised to transmit?
   2. Destination correlation: Is data going to a legitimate vendor infrastructure?
   3. Transmission security: Is the method appropriate and approved?

If any validation fails, transmission is blocked instantly, before data leaves the device.

This creates the data protection confidence you need for operational resilience. When incidents occur, you immediately know which applications attempted what transmissions where. No forensic investigation. No assumptions. Just facts.

Strategic incident response based on actual risk, not fear.

FCA operational resilience deadline: 31 March 2025.

After that date, you’re expected to remain within impact tolerances during severe but plausible disruptions. Cyber-attacks qualify as 31% of incidents are ransomware, 58% face supply chain attacks.

When those incidents occur, can you maintain important business services? Or do you breach impact tolerances because you lack confidence in client data protection?

That’s the real test of operational resilience.

Framework documentation gets you compliance paperwork. Application data protection gets you operational capability.

One satisfies auditors. The other satisfies clients when competitors are offline.

We’ve made strong claims about application data flows your security stack doesn’t see. Don’t trust claims. Instead, verify with evidence from your own environment.

10 devices. 10 days. We’ll show you actual unauthorised application data flows: CRM synchronisation going through ISPs instead of directly to vendors, Excel exports to unapproved cloud storage, and custom application data to non-business endpoints.

Not theoretical vulnerabilities, but real data flows from Salesforce, Dynamics, portfolio management tools, and wealth management platforms in your infrastructure.

Then you decide: fill the gap before March 2025, or accept that you can’t demonstrate operational resilience during incidents.

At least you’ll know the gap exists. Most firms don’t realise until they’re filing FCA incident reports explaining why they breached impact tolerances.

Don’t be the next firm that discovers application data walked out while DLP watched the email.

Q. Does this replace our existing DLP?
No. Application data protection complements DLP. Your DLP continues protecting email and web data; ZORB protects desktop application data. Providing defence-in-depth without disruption.

Q. How does this help meet FCA operational resilience requirements?
By providing the data protection confidence you need to maintain important business services during incidents. Instead of a wholesale shutdown, you make strategic decisions about which services continue based on actual risk.

Can we see this gap in our own CRM systems?
Yes. Our proof-of-value assessment shows actual application data flows from your Salesforce, Dynamics, and custom CRM systems. Giving you real evidence of what your current security stack doesn’t monitor.

Q. What about our existing EDR and network security?
They continue protecting devices and the network perimeter. ZORB fills the application data gap between device protection and network security by correlating which application is sending what data where.

Q. How long until we see results?
10 days. Most financial services firms discover 15-30% of CRM application traffic going through unexpected routes. Not necessarily malicious, just unmonitored. But during incidents, unmonitored equals unprotected.