Dan Chernov, DerScanner

 

Financial Service Delphi Security: GDPR and PCI DSS compliance

 

Although often described as “legacy”, Delphi continues to power thousands of mission-critical systems in the financial services sector. These systems are mostly valued for their performance, speed, reliability, and efficient decades-old business logic. However, as the industry continues to grow, financial applications handle an increasing amount of sensitive data, creating a challenging security landscape where compliance with data security regulations, such as GDPR and PCI DSS is critical.

 

Both demand strict measures to protect sensitive user data, and companies that fail to comply risk hefty financial penalties and legal actions. For Delphi-based systems, compliance can be even more challenging, especially when integrating legacy code with modern platforms.

 

In this article, we’ll cover how to ensure GDPR and PCI DSS compliant Delphi applications. First, we overview the cost of non-compliance. We then cover the requirements for both regulations and, lastly, how you can automate compliance using static code analysis. 

 

The Cost of Non-Compliance

 

A single vulnerable line of code in your Delphi payment processing system can result in regulatory violations, potentially leading to financial penalties and even operational consequences. In 2025, the average cost of a data breach reached an all-time high of $4.45 million, with regulatory fines making up a small percentage of this figure. Proof that the financial impact of security failures in regulated environments extends far beyond fines and technical remediation, albeit, depending on the law, the size of your business, and the severity of the violation.

 

Below is an overview of financial fines for GDPR and PCI DSS non-compliance:

 

Regulation	Penalties	Violations
GDPR	Tier 1: Up to €10M or 2% of global annual revenue from the preceding financial year. Tier 2: Up to €20M or 4% of global annual revenue from the preceding financial year.	Tier 1: less severe infringements, such as a lack of data protection policies and failing to keep proper records. Tier 2: The more serious infringements, including illegal data processing, and anything that goes against the right to consumer privacy.
PCI DSS	1–3 months: $5,000–$10,000/month 4–6 months: $25,000–$50,000/month 7+ months: $50,000–$100,000/month	Absence of vulnerability scans, improper storing of cardholder data, etc.

 

While the PCI DSS row indicates that you may be fined up to $100,000 per month for non-compliance, if that violation leads to a breach, the financial consequences are far more severe. In other words, fines are just the tip of the iceberg; the real damage often lies in what comes next. This can include forensic investigations, legal fees, settlements, and regaining public trust or rebuilding reputation. 

 

A perfect example is the 2013 Target data breach, which compromised 40 million payment cards. The company incurred almost $300 million in settlements, legal fees, and compensation.

 

Similarly, in 2023, Meta violated GDPR rules by transferring user data to the US without ensuring adequate protection, and was fined €1.2 billion and also ordered to suspend Facebook’s EU data flows. 

 

GDPR Requirements for Delphi Applications

 

GDPR imposes strict requirements on how financial software must handle user data. For Delphi applications, this compliance requires embedding the following data protection principles from the initial development stages. 

 

 

Data Minimisation

 

Delphi applications should collect and process only the data necessary for their intended function. For example, a loan processing system may not need to log IP addresses, while a payments engine should avoid storing full personal identifiers in transaction logs. This may require periodic code reviews to eliminate unnecessary fields and legacy processing routines that retain redundant data.

 

Pseudonymisation and Encryption

 

Personal data handled in Delphi systems must be pseudonymised or encrypted both at rest and in transit. AES encryption for database fields, TLS 1.2/1.3 for API calls, and pseudonymization techniques (such as replacing identifiers with tokens) reduce privacy risks while still enabling legitimate business functions, including fraud detection, analytics, and regulatory reporting.

 

Data Protection Impact Assessments (DPIAs)

 

High-risk processing activities, for example, integrating AI-driven credit scoring into a Delphi application, adding biometric authentication, or deploying large-scale customer analytics, must undergo a DPIA before implementation. These assessments help identify risks and define mitigation strategies before deployment, ensuring proactive compliance

 

Privacy Driven Defaults

 

Default configurations in Delphi applications should prioritise customer privacy. For instance, banking solutions should have optional features like geolocation or marketing communications turned off by default, requiring explicit opt-in from customers.

 

PCI DSS Requirements for Delphi Applications

 

PCI DSS establishes 12 core requirements to achieve compliance. However, the following technical requirements dictate how financial applications must handle cardholder data.

 

Protect Stored Cardholder Data

 

Protect Stored Cardholder Data (Requirement 3)

 

PCI DSS requires that Delphi applications that store cardholder data use strong encryption algorithms like AES-256. Sensitive fields, such as the Primary Account Number (PAN), should never be stored in plaintext, and authentication data (e.g., CVV/CVC codes or magnetic stripe data) must never be retained post-authorisation. Developers should implement proper key management, avoiding hardcoded keys in source code, and using secure key vaults or HSMs (Hardware Security Modules).

 

Encrypt Transmission of Cardholder Data (Requirement 4)

 

When Delphi applications transmit cardholder data, for example, during payment authorisation calls to a gateway, the transmission must be encrypted using secure protocols like TLS 1.2 or TLS 1.3. Outdated SSL or weak cipher suites should be strictly disabled. Delphi’s modern libraries (Indy components or third-party secure socket libraries) should be configured to enforce strong cryptography standards, protecting against eavesdropping and man-in-the-middle attacks.

 

Maintain Secure Systems and Applications (Requirement 6)

PCI DSS emphasises that applications must remain free from known vulnerabilities. For Delphi systems, this can mean:

• Employing static analysis to catch SQL injection, buffer overflows, and insecure cryptographic implementations.
• Keeping Delphi runtime libraries and third-party components patched.

 

Implement Strong Access Control Measures (Requirement 7)

Access to cardholder data within Delphi applications should follow the principle of least privilege. This requires:

• Role-based access controls (RBAC) built into application logic.
• Enforcing strong authentication for administrative users, ideally with multi-factor authentication.
• Logging and monitoring all access attempts, with alerts for unusual activity.

 

 

Static Code Analysis for Compliance Automation

 

Manual regulatory compliance, although relatively straightforward, can be time-consuming, error-prone, expensive, and challenging to scale with current market conditions and requirements. 

 

Against this backdrop, static code analysis (SCA) offers an automated approach that allows you to address compliance and security concerns early in the Software Development Life Cycle (SDLC). By analysing the source code, SCA tools can identify insecure Delphi coding practices, such as SQL injection and buffer overflows, which is critical for PCI DSS compliance (requirement 6).

 

More specifically, DerScanner’s SAST (Static Application Security Testing) uncovers vulnerabilities in both source and binary files, a critical feature for legacy systems like Delphi, where access to source code may be restricted. This solution is a Mitre-certified and CWE-compatible solution that automatically maps the findings in your analysis against GDPR and PCI DSS standards, amongst others. 

 

DesScanner also includes DerCodeFix, which goes beyond detection to instant remediation. It generates production-ready code that ensures compliance, providing detailed information behind each solution. 

 

For a practical guide on how to meet compliance requirements using DerScanner, check out the video below.

 

 

Conclusion

 

PCI DSS and GDPR compliance must be integrated from the start and throughout the Software Development Lifecycle (SDLC). This “shift left” approach means that compliance isn’t treated as an afterthought, and developers can address security standards early in the development process. Static code analysis makes it easy to implement this approach. The best ones, like DerScanner, not only map vulnerabilities against corresponding standards, but also offer automated remediation.