Financial Services Security.
Zero Trading Disruption.
Comprehensive security testing across the full financial services attack surface — internet and mobile banking, SWIFT infrastructure, payment card environments, active directory, and core banking networks — with built-in PCI DSS v4.0, SWIFT CSP CSCF v2024, DORA, SOX ITGC, and GLBA regulatory mapping.
SWIFT CSP CSCF v2024
6 financial attack surfaces
DORA & SOX ITGC mapping
Zero-downtime protocols
Financial Services: The Highest-Value Target in Cybersecurity.
Banks and financial institutions face a threat environment unlike any other sector — combining nation-state attackers, organised financial crime, insider risk, and the most complex regulatory landscape in enterprise technology.
Four Constraints That Define Financial Services Testing.
Layered Regulatory Obligations
PCI DSS v4.0 (March 2025 mandatory), SWIFT CSP CSCF v2024, DORA (EU), SOX ITGC, GLBA, and regional requirements such as NCA ECC and UAE CBUAE circular all apply simultaneously — often to different system components within a single institution. Findings must reference the specific control section, not just the regulation name.
Continuous Availability Requirements
Core banking, payment processing, and trading infrastructure must remain available 24/7/365. Testing windows are narrow, often restricted to off-peak hours with strict monitoring from operations teams. Any test activity that could affect transaction processing throughput, settlement cycles, or real-time gross settlement feeds requires explicit pre-approval and a documented rollback protocol.
Nation-State & Organised Crime Threat Actors
Financial institutions are primary targets for SWIFT heist campaigns, ransomware groups with dedicated financial sector arms, and nation-state espionage focused on market intelligence. Threat modelling for financial environments must account for adversaries with extended dwell times, custom tooling, and the resources to acquire zero-day vulnerabilities targeting financial middleware.
Highly Interconnected Legacy Systems
Core banking platforms from the 1970s–1990s operate alongside modern REST APIs, cloud-native microservices, and real-time payment rails. This creates hidden trust relationships and protocol translation points — SWIFT message brokers, MQ-Series queues, ISO 20022 gateways — where security controls vary significantly and a misconfiguration in one layer can cascade silently to another.
Six Financial Layers. Tested Systematically.
Select a layer to see what gets tested, how, and which regulations require it.
Internet & Mobile Banking Applications
Web portals · iOS / Android apps · Open Banking APIs (PSD2/CDR) · Customer-facing APIs
- Authentication security: multi-factor bypass, OTP brute-force, SIM-swap attack surface in phone-bound authentication flows
- Broken Object-Level Authorisation (BOLA): account number substitution in API endpoints to access third-party account balances and transaction history
- Session management: token entropy, concurrent session policy, JWT algorithm confusion (RS256→HS256), and session fixation vectors
- Open Banking API scope enforcement: whether OAuth tokens granted narrower scopes honour the principle of least privilege in practice
- Mobile application binary security: certificate pinning, root/jailbreak detection, local credential storage in SQLite, Keychain, and SharedPreferences
- Transaction manipulation: parameter tampering on transfer amounts, currency codes, beneficiary IBANs, and reference fields before submission
CRITICAL
BOLA : Cross-Account Transaction History Access via IDOR
GDPR Art. 32
DORA Art. 9(2)
Authenticated session token from Account A accepted in requests for Account B’s transaction endpoint. Twelve months of full transaction history returned without triggering any fraud alert or audit log entry. No rate-limiting applied to sequential enumeration attempts.
SWIFT Infrastructure & CSP Controls
Alliance Access · Alliance Messaging Hub · SWIFT service bureau · ISO 20022 gateways
- SWIFT operator workstation access control and multi-person authorisation enforcement for high-value message release
- SWIFT back-office server patching status and compliance against CSCF v2024 mandatory controls (M1–M31)
- Endpoint security on SWIFT-connected servers: AV/EDR coverage, application whitelisting, local admin privilege exposure
- Segregation of SWIFT environment from general corporate network — network ACL validation between SWIFT Zone and enterprise DMZ
- SWIFT Alliance Access operator privilege review: user-to-authoriser separation, orphaned accounts, inactive operator detection
- Message monitoring and anomaly detection: whether the institution’s SWIFT Payment Controls solution is correctly scoped and active for outbound MT103/202 messages
CRITICAL
SWIFT Zone Network Segmentation Failure : Corporate Workstation Reachable to Alliance Access
SWIFT CSCF v2024 Control 2.4
Firewall ruleset permits unrestricted TCP from the general user VLAN directly to the SWIFT server subnet. Lateral movement from a compromised user workstation reaches the Alliance Access administrative interface on TCP/6000 without traversing any inspection point. SWIFT CSCF mandatory control 1.1 (restrict internet access) and 2.4 (operator PC segregation) both violated.
Payment Card Environment (PCI DSS v4.0)
Cardholder Data Environment (CDE) · Point-of-Sale · Payment gateways · Tokenisation vaults
- Cardholder Data Environment scoping validation: discovery of systems storing, processing, or transmitting PAN data outside the declared CDE boundary
- Network segmentation testing between CDE and out-of-scope systems: firewall rule analysis and active traffic-path testing (PCI DSS v4.0 Req 1.3)
- PAN data exposure in logs, error messages, API responses, and memory dumps — systematic scan across application tiers and middleware
- Cryptographic control validation: whether PAN storage uses strong one-way hashing, truncation, or tokenisation (Req 3.5); key management lifecycle review
- E-commerce Magecart detection: integrity of payment-page scripts, Content Security Policy enforcement, and subresource integrity on third-party script loads
- Authenticated scan and penetration test across all CDE-facing systems per PCI DSS v4.0 Requirement 11.4.3 penetration testing methodology
CRITICAL
PAN Data in Application Debug Logs — Out-of-Scope Log Server
PCI DSS v4.0 Req 10.3.1
Application debug logging writes the full 16-digit PAN to disk on payment validation failures. The log aggregation pipeline ships these logs to a Splunk instance explicitly excluded from the CDE scope, extending cardholder data exposure to a system with no compensating controls. Estimated 3,200 PANs present in the log index at time of discovery.
Identity & Privileged Access Management
Active Directory · Privileged Access Workstations · PAM solutions · Service accounts · API credentials
- Active Directory attack paths: Kerberoasting, AS-REP Roasting, DCSync rights, unconstrained delegation exposure across domain trusts
- Privileged account discovery and credential exposure: service account password age, SPN misconfiguration, LSA secret extraction potential from domain-joined servers
- Non-Human Identity (NHI) exposure: API keys, service account tokens, and automation credentials embedded in CI/CD pipelines, configuration repositories, and deployment scripts
- Privileged Access Management coverage gaps: identification of administrative accounts that bypass PAM vault requirements and authenticate directly to sensitive systems
- Inter-domain and cross-forest trust exploitation paths: identifying attack routes between subsidiary entities, acquired companies, and outsourced IT environments sharing AD infrastructure
- Just-in-time access control validation and standing privilege audit across Tier-0 and Tier-1 administrative assets
CRITICAL
Unconstrained Kerberos Delegation on Core Banking Application Server
SOX ITGC AC-2
GLBA Safeguards Rule
Core banking application server configured with unconstrained Kerberos delegation. An attacker with any access to this server can coerce Kerberos authentication from the domain controller and extract the krbtgt hash, enabling domain-wide golden ticket attacks. The server is reachable from the general user VLAN without multi-factor authentication.
Core Banking Systems & Network Infrastructure
Temenos T24 · Finastra Fusion · Finacle · Internal payment switches · Data centre network fabric
- Core banking platform authentication: administrative console access, default credential exposure, and session management on management interfaces
- Internal payment switch security: ISO 8583 message manipulation, host security module (HSM) network exposure, and payment routing logic validation
- Network segmentation between production, DR, UAT, and development environments: lateral movement paths from lower-security environments to production data
- Internal DNS and routing security: DNS poisoning attack surface on internal resolvers, BGP route manipulation risk for internet-facing AS infrastructure
- Firewall ruleset review and active path testing: identifying overly permissive east-west rules that enable lateral movement between banking application tiers
- Disaster recovery and backup infrastructure security: backup server access controls, encryption of backup media, and restoration authentication requirements
HIGH
Development Environment Database Contains Production Customer Records
PCI DSS v4.0 Req 6.3.2
DORA Art. 9(2)
Development database is a direct replica of the production customer database, including full account details, transaction history, and identity documents. Accessible from all developer workstations without VPN segregation or data masking. 2.3 million customer records exposed to a population of 180 developers with no activity monitoring.
Regulatory Evidence & Audit Readiness
PCI DSS QSA support · Internal audit packages · Regulatory submission artefacts · Board-level reporting
- PCI DSS v4.0 penetration testing evidence package: scoped test plan, methodology documentation, finding reports, and remediation verification aligned to Requirement 11.4
- SWIFT CSP CSCF self-attestation support: evidence mapping from penetration test findings to mandatory and advisory controls, supporting the annual KYC-SA submission
- DORA ICT risk assessment documentation: technical findings packaged for inclusion in the institution’s ICT risk register and third-party risk management framework under Article 6
- SOX ITGC change management control testing: validation that application and infrastructure change processes enforce segregation of duties and approval workflows
- Regulatory control gap analysis: formal mapping of identified vulnerabilities against the specific control number — not just the regulation name — for each applicable framework
- Board and executive reporting templates: risk-quantified summaries translating technical findings into financial exposure, regulatory breach risk, and remediation investment justification
REPORT
PCI DSS v4.0 Penetration Test Report Package
PCI DSS v4.0 Req 11.4.4
Each finding includes: CVSS v4.0 base and environmental score, specific PCI DSS requirement reference (e.g., Req 6.2.4.c), evidence artefact (screenshot, request/response, or tool output), remediation instruction at the configuration level, and a re-test verification protocol. Segmentation testing results documented separately per Requirement 11.4.5.
Every Finding Tagged to Your Specific Regulatory Obligation.
Financial institutions operate under overlapping regulatory frameworks. Findings from each layer are mapped to the specific control number — not just the regulation name.
Global
The Payment Card Industry Data Security Standard version 4.0 became mandatory in March 2025, replacing v3.2.1. Requirement 11.4 mandates an annual penetration test covering internal and external systems in the CDE, explicit network segmentation validation (11.4.5), and authenticated vulnerability scanning (11.3). Version 4.0 adds customised approach options and increased requirements for e-commerce script integrity.
Global
The Customer Security Programme’s Customer Security Controls Framework v2024 contains 31 mandatory controls (M1–M31) and 6 advisory controls. Institutions must annually self-attest compliance via the KYC-SA portal. Mandatory controls cover SWIFT environment segregation, endpoint protection, operator account management, and transaction anomaly detection. Penetration testing evidence directly supports attestation for controls 1.1, 2.4, 4.1, and 5.4.
European Union
The Digital Operational Resilience Act applies to over 22,000 EU financial entities from January 2025. Article 26 mandates Threat-Led Penetration Testing (TLPT) for significant financial entities, following the TIBER-EU framework. Articles 9–12 require comprehensive ICT risk management, vulnerability management, and incident classification. Findings map directly to the ICT risk register obligations under Article 6.
United States
Sarbanes-Oxley IT General Controls testing for Section 404 compliance covers logical access controls (AC), change management (CM), computer operations (CO), and programme development (PD). ITGC deficiencies can escalate to significant deficiencies or material weaknesses in the auditor’s report. Penetration testing evidence directly supports AC testing by demonstrating whether access controls operate as designed under adversarial conditions.
United States
The Gramm-Leach-Bliley Act Safeguards Rule (16 CFR Part 314, updated 2023) requires financial institutions to implement a comprehensive information security programme including penetration testing. The updated rule specifies annual penetration testing of systems containing customer Non-Public Personal Information (NPPI) and biannual vulnerability assessments. Findings must be reported to the Board of Directors or a designated committee.
Saudi Arabia
The National Cybersecurity Authority’s Essential Cybersecurity Controls apply to all government organisations and their contractors in Saudi Arabia, including financial institutions. The framework covers five main domains: cybersecurity governance, risk management, compliance, operational technology security, and third-party security. Penetration testing evidence maps to Domain 3 (Cybersecurity Operations and Technology) control areas 3-15 through 3-17.
Zero Trading Disruption. Full Regulatory Evidence.
Operations-Coordinated Test Windows
Every engagement is coordinated with treasury operations, IT on-call, and compliance teams before a single packet is sent. Testing windows are defined around settlement cycles, end-of-day processing, and regulatory reporting deadlines. Active testing against payment infrastructure includes a documented halt protocol: a single contact can stop all active test activity within two minutes. We do not test within trading hours without explicit written authorisation from the CISO and operations lead.
Cardholder and Customer Data Aware Tooling
Test tooling is configured with financial data pattern detection — PAN formats (all major networks), IBAN structures, account number patterns, SORT codes, BIC/SWIFT codes, and national identification number formats across 40+ jurisdictions. Any intercepted or captured data matching these patterns is flagged and anonymised before being written to test artefacts. Customer financial data is never retained in penetration test reports, logs, or exported tool outputs.
Audit-Ready Regulatory Evidence Packages
Deliverables are structured for direct use in regulatory submissions, QSA engagements, and internal audit processes — not generic penetration test reports that require manual mapping. Each finding includes the specific PCI DSS requirement number, SWIFT CSCF control reference, or DORA article citation that applies. Segmentation test evidence, CDE scope diagrams, and re-test verification records are included as standard deliverables for PCI-scoped engagements.