Fintech companies sit at the intersection of technology and financial regulation, which means they inherit the security testing obligations of both. A payments startup processing card transactions faces PCI DSS. A B2B lending platform selling to enterprise customers faces SOC 2. A digital bank licensed in Singapore faces MAS TRM. A European neobank faces DORA. A UK-regulated payment institution faces FCA requirements. Most fintechs face several of these simultaneously.
The challenge is that each framework has a different penetration testing requirement, a different evidence standard, and a different audit cycle. Building a security testing program that satisfies all applicable frameworks without duplicating effort or creating evidence gaps requires mapping each obligation clearly before designing the testing program.
This guide maps the regulatory penetration testing landscape for fintech companies across six major frameworks, identifies where they overlap and where they diverge, and explains what an efficient multi-framework compliance testing program looks like.
Most non-financial technology companies face one or two compliance frameworks driving their security testing program. Fintech companies typically face three to five, because they combine software development (bringing SOC 2 and ISO 27001 obligations from enterprise customer requirements) with financial services operations (bringing sector-specific regulatory requirements).
The key frameworks and which fintechs they apply to:
| Framework | Applies to | Penetration testing obligation |
|---|---|---|
| PCI DSS | Any entity storing, processing, or transmitting card data | Annual (Req 11.4.1, 11.4.2) + post-change + segmentation testing |
| SOC 2 | B2B SaaS companies with enterprise customers | Annual during audit period (CC6, CC7) |
| DORA | EU-regulated financial entities and critical ICT providers | Threat-led penetration testing (TLPT) every 3 years for significant firms |
| MAS TRM | Singapore-licensed financial institutions | Annual + post-change, per 2021 guidelines |
| FCA / PRA | UK-regulated payment institutions and banks | CBEST for systemic firms; general security testing expectations for others |
| FFIEC | US banks and bank-adjacent fintech (BaaS, embedded finance) | Regular security testing per IT Examination Handbook |
Any fintech that stores, processes, or transmits payment card data falls under PCI DSS. This includes payment gateways, card issuing platforms, buy-now-pay-later providers, and any software that touches card numbers in transit.
PCI DSS Requirement 11.4 is explicit: external and internal penetration testing at least annually, segmentation testing every six months when segmentation is used to limit cardholder data environment scope, and penetration testing after any significant change to CDE infrastructure.
The "significant change" trigger is the most operationally demanding requirement for actively developing fintechs. Every infrastructure change touching or adjacent to the CDE requires penetration testing. For fintech engineering teams shipping frequently, this creates a testing cadence that annual manual engagement scheduling cannot satisfy.
PCI DSS penetration testing requirements explained covers the full Requirement 11.4 obligations including the 11.4.3 segmentation testing requirement that many fintechs miss until their first QSA review.
The API layer is where most PCI findings concentrate in fintech environments. Payment APIs accepting card data, processing webhook callbacks from payment processors, and exposing transaction data to partner platforms are high-value targets that require specific API security testing methodology beyond standard web application assessment. API vulnerabilities standard penetration tests miss covers the eight API-specific classes most commonly absent from fintech PCI assessments.
For B2B fintech companies selling to enterprise customers (lending platforms, treasury management tools, payroll providers, insurance technology: SOC 2 is typically the first compliance framework required by procurement teams.
SOC 2 does not mandate penetration testing by name but creates the obligation indirectly through Trust Service Criteria CC6.1 (logical access controls), CC6.6 (security over access from outside system boundaries), and CC7.1 (ongoing security monitoring). Annual penetration testing during the SOC 2 audit period is the standard approach to satisfying these criteria.
For fintech companies pursuing SOC 2 Type II, the audit period is typically twelve months, and the penetration test must have been conducted within that period. A penetration test conducted before the Type II period started does not produce audit-period evidence.
SOC 2 penetration testing: what auditors actually require covers the specific criteria and what QSAs and auditors examine in the evidence package.
The EU Digital Operational Resilience Act came into full effect in January 2025 and applies to EU-regulated financial entities including banks, payment institutions, e-money institutions, crypto-asset service providers, and critically, the ICT third-party service providers that serve them.
DORA introduces Threat-Led Penetration Testing (TLPT) as a specific requirement for significant financial entities. TLPT is not standard penetration testing: it is an advanced, intelligence-led test modelled on the TIBER-EU framework, conducted by certified testers, targeting production systems with explicit regulatory oversight.
Key DORA penetration testing provisions:
TLPT frequency: At least every three years for entities within scope of the advanced testing requirement.
ICT third-party providers: Fintechs providing critical ICT services to EU-regulated financial institutions fall within DORA's scope as critical ICT third-party providers, subjecting them to DORA oversight including testing requirements.
Scope: TLPT covers production systems, not just pre-production or test environments. This distinguishes it from most standard penetration testing engagements.
Tester requirements: DORA-compliant TLPT must be conducted by certified external testers meeting specific qualification requirements set by the relevant national competent authority.
For US-headquartered fintechs with EU operations or EU-regulated financial institution customers, DORA creates compliance obligations that extend beyond their European entity to potentially cover the product and infrastructure serving EU customers.
Singapore's Monetary Authority of Singapore Technology Risk Management guidelines apply to MAS-licensed financial institutions including digital payment token service providers, digital banks, and payment institutions holding a Major Payment Institution licence.
The MAS TRM 2021 guidelines require annual penetration testing of internet-facing systems and critical systems, with post-change testing required following significant infrastructure changes. The post-change requirement directly parallels PCI DSS's significant change trigger and creates the same operational challenge for actively developing fintech platforms.
For Singapore-licensed fintechs, MAS TRM and PCI DSS obligations frequently apply simultaneously for payment-processing operations. A single well-scoped penetration test can satisfy both frameworks' annual requirements, provided the scope covers the cardholder data environment (for PCI) and the internet-facing and critical systems (for MAS TRM).
MAS TRM penetration testing requirements covers the specific gaps most Singapore fintechs carry in their current testing programs. VAPT services in Singapore covers the local engagement options for MAS-scoped testing.
UK-regulated payment institutions, electronic money institutions, and banks regulated by the Financial Conduct Authority or Prudential Regulation Authority face security testing expectations that differ by firm size and systemic importance.
CBEST is the Bank of England's cyber resilience assessment framework for systemically important financial institutions. It is an intelligence-led, threat-based penetration testing framework modelled on the TIBER-EU approach and requiring advanced red team exercises rather than standard penetration testing. CBEST applies to the largest UK banks and payment infrastructure operators, not to most fintech companies.
CQUEST is a similar framework for smaller but still significant financial institutions in the UK.
General FCA expectations: For payment institutions and electronic money institutions that are not subject to CBEST or CQUEST, the FCA's general operational resilience and cybersecurity expectations create implicit security testing obligations. FCA supervisory reviews and regulatory enforcement actions have cited inadequate security testing as a contributing factor in cybersecurity incidents, creating practical if not prescriptive testing obligations.
US fintechs operating in embedded finance, Banking-as-a-Service, or providing technology to regulated banks fall under FFIEC oversight through their bank partners and through direct examination if they qualify as technology service providers to examined institutions.
The FFIEC Information Security Booklet and Cybersecurity Assessment Tool create expectations for regular security testing at financial institutions. Fintechs that are technology service providers to examined banks are subject to security review as part of those banks' vendor risk management obligations.
For BaaS providers and embedded finance infrastructure companies, this means their bank partners' examination pressure flows downstream: bank examiners ask what security testing their technology service providers conduct, and fintechs that cannot demonstrate regular penetration testing create compliance risk for their bank partners.
Beyond the framework obligations, fintech companies have specific attack surface characteristics that shape what penetration testing must cover.
Open banking APIs: PSD2 in Europe and equivalent open banking regulations in the UK, Australia, and Singapore mandate that regulated financial institutions expose APIs to third parties. These APIs represent high-value attack surfaces: they carry financial data, execute transactions, and are accessible to any registered third-party application. API vulnerabilities standard penetration tests miss maps the eight API-specific classes that standard penetration testing methodology frequently undercovers.
Payment flow integrity: Transaction manipulation, double-spending, fee avoidance, and balance manipulation are business logic vulnerabilities specific to financial applications. Standard penetration testing methodologies that do not specifically test financial workflow integrity miss this entire category. What a real web application penetration test should cover maps the business logic coverage dimension that must be explicitly scoped for financial application testing.
Multi-tenant data isolation: SaaS fintech platforms serving multiple financial institution customers or business clients must enforce strict data isolation between tenants. Authorization gap testing across tenant boundaries is a critical coverage dimension that must be explicitly scoped: standard penetration testing that tests a single authenticated session does not test cross-tenant data isolation.
Third-party and embedded finance integration points: Fintechs connecting to bank APIs, payment processors, credit bureaus, and KYC providers create integration surfaces with distinct security profiles. The integration layer between the fintech application and each third-party connection is a scope component that frequently falls outside standard testing boundaries.
The most operationally efficient approach for a fintech facing multiple concurrent framework obligations is a testing program designed to produce evidence that satisfies all applicable frameworks simultaneously, rather than separate testing cycles for each framework.
In practice, this means:
Single annual penetration test scoped to the superset of all framework requirements. External and internal testing covering the internet-facing application surface (for SOC 2, MAS TRM, and PCI DSS), the cardholder data environment and segmentation validation (for PCI DSS specifically), and API security testing (for open banking and payment API surfaces). One assessment, evidence applicable to all frameworks.
Post-change testing aligned to deployment cycles. Both PCI DSS and MAS TRM create post-change testing obligations that annual-only programs cannot satisfy. Continuous penetration testing and how it differs from annual pentests covers the operational model that satisfies post-change requirements without scheduling a new manual engagement for every deployment.
Framework-specific evidence formatting. Different frameworks require different report formats and evidence packages. A QSA reviewing PCI DSS evidence wants different documentation than a SOC 2 auditor. Confirming report format with each framework's auditor before the engagement starts (not after the report is delivered): this avoids the cost of producing the same engagement evidence in multiple formats.
Evidence record continuity across audit periods. For SOC 2 Type II (12-month audit period), DORA (3-year TLPT cycle), and MAS TRM (annual with post-change), maintaining a continuous evidence record rather than point-in-time reports becomes the documentation standard that satisfies all three simultaneously. How agentic pentesting produces a continuous compliance evidence record covers how continuous testing generates this record as an operational output rather than a documentation project.
For penetration testing services in the US structured to produce multi-framework compliance evidence, or PTaaS for continuous coverage that satisfies post-change testing obligations, the 10x Pentest platform covers the application and API layer testing that fintech compliance programs require. What is inside a VAPT report covers the evidence standard that satisfies auditors across PCI DSS, SOC 2, and MAS TRM simultaneously. See pricing or get in touch to discuss structuring a testing program around your specific regulatory obligations.
Q1. What penetration testing does a fintech company need?
The penetration testing a fintech needs depends on which frameworks apply. Payment-processing fintechs need PCI DSS Requirement 11.4 compliance: annual external and internal penetration testing, plus segmentation testing and post-change testing. B2B fintech companies with enterprise customers typically need annual penetration testing to satisfy SOC 2 audit requirements. EU-regulated fintech entities and critical ICT providers to EU financial institutions face DORA obligations including threat-led penetration testing every three years. Singapore-licensed fintechs face MAS TRM annual testing requirements. Most fintech companies face at least two of these frameworks simultaneously.
Q2. How often does a fintech company need to conduct penetration testing?
At minimum annually, often more frequently. PCI DSS requires annual testing plus testing after significant changes to the cardholder data environment. MAS TRM requires annual testing plus post-change testing. SOC 2 requires testing within each 12-month audit period. DORA requires threat-led penetration testing at least every three years for significant entities. The post-change testing requirements in PCI DSS and MAS TRM mean that actively developing fintechs need more than one annual engagement: continuous penetration testing that triggers on deployment events is the operationally efficient model for managing post-change obligations.
Q3. What is DORA and does it apply to fintech companies?
DORA (Digital Operational Resilience Act) is an EU regulation that came into full effect in January 2025. It applies to EU-regulated financial entities including payment institutions, e-money institutions, crypto-asset service providers, and banks. It also applies to critical ICT third-party providers serving EU-regulated financial entities. US-headquartered fintechs with EU-licensed entities or that provide critical ICT services to EU-regulated financial institutions fall within DORA's scope. DORA introduces threat-led penetration testing (TLPT) modelled on the TIBER-EU framework for significant entities, requiring advanced red team exercises under regulatory oversight every three years.
Q4. What is TLPT and how does it differ from standard penetration testing?
Threat-Led Penetration Testing (TLPT) is an advanced, intelligence-led penetration testing approach required under DORA for significant EU financial entities. Unlike standard penetration testing, TLPT is conducted against production systems (not pre-production environments), requires certified external testers meeting regulatory qualification requirements, is based on threat intelligence specific to the organisation's threat model, and is conducted under oversight from the national competent authority. TLPT typically takes three to six months and resembles a red team exercise more than a standard penetration test. Most fintech companies subject to DORA are not in the initial cohort required to conduct TLPT: the initial scope covers the largest and most systemically significant entities.
Q5. Can one penetration test satisfy multiple compliance frameworks?
Yes, if scoped correctly. A penetration test covering the external application surface, API layer, internal network, and cardholder data environment with appropriate segmentation testing can simultaneously satisfy PCI DSS Requirement 11.4, SOC 2 CC6 and CC7 evidence requirements, MAS TRM internet-facing and critical system testing requirements, and ISO 27001 Annex A 8.8 technical vulnerability management obligations. The key is confirming the scope and evidence format with each framework's auditor before the engagement, not after. Different auditors expect different report sections and evidence packages: producing the right format for all frameworks from a single engagement requires explicit pre-engagement planning.
Cloud security assessments cover IAM configuration, network controls, storage access, workload security, and logging. This guide maps what each domain tests and what findings look like.
Tejas Dhokane Aug 26, 2026 
Penetration testing without a complete rules of engagement document is a legal and operational risk for both sides. This guide covers every clause and what goes wrong when it is missing.
Tejas Dhokane Aug 26, 2026 
Third-party risk assessment programmes use penetration testing evidence in two ways: requiring it from vendors, and producing it for customers. This guide covers both roles and how to evaluate vendor pentest reports.
Tejas Dhokane Aug 26, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
