Lesson 1.1: Data Breach at Fintech Company Figure Technology Solutions Deep Dive

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: Data Breach at Fintech Company Figure Technology Solutions Deep Dive! Over the next 45 minutes, we will explore the anatomy of a major data breach, focusing on the real-world incident at Figure Technology Solutions. We'll look at how it happened, what was exposed, and the defensive lessons every organisation can use.

But first, let me tell you about Marcus Webb.

It's 3:15 PM on a Tuesday in late February. Marcus Webb, a senior security analyst at Figure Technology Solutions in San Francisco, is reviewing a routine alert from the company's data loss prevention system. The office hums with the low chatter of developers and the faint smell of coffee from the kitchen. His screen shows a minor policy violation flag, nothing out of the ordinary for a fintech company handling loan applications.

He dismisses the alert, marking it as a false positive. A week later, a different, more persistent alert appears. This one suggests an unusual volume of data queries from an internal development server to a database containing customer information. The pattern is sporadic, not the clean sweep of a typical attack. Marcus wonders if it's just a new batch process being tested by the engineering team. He sends a quick email to the development lead, asking for clarification.

He gets no reply. The queries stop for a day, then resume with a slightly different pattern. By the time Marcus escalates the issue to his manager and a full investigation is authorised, it's too late. The external security researchers at vx-underground have already found the data—nearly a terabyte of it—on a hacker forum. The decision to wait, to assume it was internal testing, was the pivotal moment. The breach was now public.

This is the story of the Figure data breach. By the end of this lesson, you'll understand exactly why Marcus never stood a chance against this specific attack chain, and more importantly, what monitoring and controls could have saved him and the company.

Content Section 1: What Happened at Figure Technology Solutions?

Think of a data breach not as a single event, but as a series of small failures—a door left unlocked, a light ignored, a question not asked. The Figure incident is a textbook example of this cascade.

The Scale of Exposure

In February 2024, Figure Technology Solutions confirmed a data breach that impacted nearly one million people. The exposed data was extensive, including names, addresses, Social Security Numbers, and dates of birth.

The data was not encrypted at rest in the compromised database. This meant that once the attackers gained access, they could read all the sensitive customer information directly.

The breach was discovered not by Figure's internal security team, but by external cybersecurity researchers. These researchers found 1.2 TB of the company's data publicly available on a hacker forum, which included the personal information of 950,000 individuals.

The Business and Regulatory Impact

Figure Technology Solutions is a fintech lender. Its business relies entirely on trust—trust to handle loan applications, trust to manage financial data. A breach of this scale directly attacks that foundation.

The types of data lost are considered high-value on criminal markets. Full names, addresses, and Social Security Numbers can be used for identity theft and fraud. For the affected individuals, the risk of financial crime became real and immediate.

DORA Article 5-17 DORA's ICT risk management framework requires financial entities like Figure to have strong mechanisms for identifying, classifying, and documenting critical assets. The exposure of an unencrypted database containing core customer data suggests a failure in this fundamental asset management and protection duty.

ISO A.5 ISO 27001 A.5 mandates that information security policies are established and reviewed. The breach indicates a potential gap where policies around data encryption at rest and access control for development environments were either insufficient or not properly enforced.

Content Section 2: The Attack Chain: How Did They Get In?

Understanding the likely path of this breach reveals why it's so effective and hard to stop. Let me show you exactly how an attacker might have moved from a small foothold to stealing a terabyte of data.

Reconstructed Attack Flow

Step 1: Initial Access. While the exact method isn't detailed in the public report, breaches of this nature often start with a compromised credential or a vulnerability in a public-facing system. This could be a developer's cloud console login or a misconfigured API endpoint.

Step 2: Discovery and Lateral Movement. Once inside, the attacker would have performed reconnaissance. They likely discovered a development or staging server that had overly permissive network rules, allowing it to communicate with the production database containing customer records.

Step 3: Data Exfiltration. Using the development server as a hop point, the attacker initiated queries to the production database. The sporadic, unusual query patterns Marcus saw were the exfiltration in progress. The data was then likely bundled and transferred out to an external server under the attacker's control.

The Role of the Development Environment

Development and staging systems are often the weak link in security chains. They need access to real or realistic data to function, but they rarely have the same level of security monitoring or strict access controls as production systems.

Attackers know this. They target these less-secure systems to establish a beachhead. From there, they can often find connections—like database credentials stored in configuration files—that let them pivot into the more valuable production environment.

Why Traditional Perimeter Defences Fail

Notice what all of these methods have in common. They focus on blocking *known-bad* traffic or entry points. This attack used *allowed* tools and *legitimate* pathways, making it invisible to defences that look for obvious threats.

This attack didn't need to break down the front gate. It tricked the guards into thinking it belonged inside. Here’s how common defences are bypassed:

NIST PR.AC-4 NIST CSF PR.AC-4 requires managing access permissions and authorisations. The breach suggests a failure in this control, as a development server likely had excessive permissions to query a production database containing sensitive personal data.

NIS2 Article 21 NIS2 Article 21 mandates risk management measures. A key part of this is understanding and securing interconnection points between different network zones (like development and production). The attack path exploited this specific weakness.

Content Section 3: Detection: Seeing What Marcus Missed

Marcus's system knew something was wrong. The alerts were the system trying to tell him. The challenge was interpreting a faint signal in a sea of normal noise. Here’s what to look for.

Network-Level Indicators

Volume and Destination: Look for internal servers, especially non-production ones, suddenly sending large amounts of data to external IP addresses. Even if the traffic uses allowed ports (like HTTPS over 443), the volume or destination should raise questions.

Connection Patterns: A development server making sustained, high-volume connections to a production database is unusual. Monitoring for east-west traffic anomalies is as important as monitoring north-south traffic.

Protocol Anomalies: While the queries themselves may be standard, the timing, frequency, or structure might be odd. For example, a sudden spike in SELECT queries that return entire tables, rather than specific rows.

Endpoint and Database-Level Indicators

Process Behaviour: On the database server, monitor for query processes initiated by service accounts associated with development systems running for unusually long times or consuming high amounts of memory/CPU.

Access Logs: Database audit logs are critical. They should be reviewed for successful logins and queries from unexpected source IPs or user accounts. The absence of detailed, centralised logging was a likely gap in this incident.

Identity and Credential Signals

Service Account Activity: Service accounts used by applications or development systems should have predictable behaviour. Any login from a new location or at an unusual time for that account is a major red flag.

Privilege Usage: Alert on any attempt by a low-privilege or development-focused account to access high-value data sets, like those containing full personal identifiable information (PII).

SOC2 CC6.1 SOC 2 CC6.1 requires logical access security over protected information. Effective detection, as outlined above, is part of demonstrating that control. You must be able to monitor and alert on anomalous access patterns to sensitive data, regardless of where the request originates.

GDPR Article 32 GDPR Article 32 requires a level of security appropriate to the risk, including the ability to ensure the ongoing confidentiality and integrity of processing systems. The failure to detect the exfiltration of personal data in a timely manner could be viewed as a failure to meet this security obligation.

Content Section 4: Building Your Compliance Evidence

Compliance documentation isn't just paperwork. Done right, it's the blueprint for your defence. The lessons from Figure provide concrete evidence you can use in audits.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5-17 auditors... For DORA auditors, you can now demonstrate that your team has been trained on a real-world ICT incident involving a financial entity. The activity on data flow mapping directly supports your organisation's process for identifying and classifying critical assets and their interconnections.

For ISO A.5 auditors... For ISO 27001 assessors, you can evidence that information security awareness training includes specific, current threat models (like data exfiltration via development systems). Your completion of the risk assessment activity contributes to meeting requirements for risk assessment and treatment.

For NIST PR.AC-4 auditors... For NIST CSF reviewers, you can show that you have analysed a case study highlighting the consequences of poor access control management between network zones. Your activity work maps directly to the Protect function's access control category.

Audit Trail

Document your completion of this lesson:

• Lesson title: 1.1 - Data Breach at Fintech Company Figure Technology Solutions Deep Dive
• Time invested: approximately 45 minutes
• Key learnings: Attack chains often exploit trust in internal systems; encryption at rest is a critical last line of defence; detection must focus on anomalous behaviour, not just known threats.
• Activity submission reference: Data Flow Mapping and Access Review completed.
• Follow-up actions identified: Review development environment access to production data in my organisation.

Conclusion

Let me tell you how Marcus's story ended.

The public disclosure was brutal. News outlets reported that nearly a million people's data was on a hacker forum. Marcus faced intense internal scrutiny over the dismissed alerts. While he kept his job, his confidence was shaken, and the incident became a career-defining moment he'd rather forget.

Figure Technology Solutions was forced to notify affected individuals and regulators. The company likely incurred significant costs for credit monitoring services, forensic investigation, legal fees, and potential regulatory fines. Internally, they had to overhaul their data access policies, enforce strict encryption, and implement better behavioural analytics on their database traffic.

But it doesn't have to be your story. That's why we're here.

You should now understand how a data breach can unfold through legitimate pathways, not just external attacks. You understand why encrypting sensitive data at rest is non-negotiable. You know the specific indicators that could signal data exfiltration from your databases. And you understand how to start mapping your own data flows to find weak points before an attacker does.

Next, we'll explore Next, we'll explore Lesson 1.2: Third-Party Vendor Risk in Fintech. We'll look at how breaches in your suppliers' systems can become your problem, and how to manage that chain of risk.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key detection indicators (unusual internal database queries, development system anomalies) and immediate response steps for a suspected data exfiltration incident like the Figure breach on a single page.
• Compliance Mapping Worksheet - Map your organisation's data breach controls, specifically for protecting databases and monitoring internal data flows, to the DORA, ISO 27001, NIST CSF, NIS2, SOC 2, and GDPR frameworks referenced in this lesson.
• Risk Assessment Template - Assess your organisation's specific exposure to data breach threats based on the attack vectors covered in this lesson, focusing on data store encryption status and access paths from non-production systems.
• Further reading - Links to official framework documentation (NIST SP 800-53, ISO 27002) and threat intelligence sources for tracking data breach trends and techniques.

Data Breach at Fintech Company Figure Technology Solutions Impacts Nearly 1 Million People Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026