SWIFT CSP
Compliance Guide

SWIFT CSP Penetration Testing Requirements and How Sprocket Security Satisfies Them

The SWIFT Customer Security Programme requires all SWIFT users to attest annually to a defined set of mandatory security controls with network-level penetration testing is at the center of that obligation.

Control 7.3A

Pentesting of the SWIFT infrastructure is mandatory for all SWIFT user types

Annual

Minimum testing cadence before each yearly self-attestation submission

68%

Of FS network perimeter engagements uncover a critical or high-severity finding on first test

The Requirement

What SWIFT CSP Actually Requires

The Customer Security Controls Framework (CSCF) defines 32 controls split between mandatory and advisory, and every SWIFT user must attest annually that mandatory controls are implemented.

REQUIREMENT WHAT IT MEANS IN PRACTICE HOW SPROCKET SATISFIES THE REQUIREMENT
Control 7.3A All SWIFT users must conduct penetration testing of their SWIFT-related infrastructure annually. The test must cover the local SWIFT infrastructure, secure zone boundaries, and operator workstations. Sprocket scopes testing specifically to your SWIFT infrastructure: local SWIFT footprint, operator workstations, messaging interfaces, and secure zone boundaries. Output maps to CSCF control language, not a generic pen test format your compliance team has to translate.
Control attestation SWIFT users self-attest against all mandatory controls each year. Attestation is submitted to SWIFT and shared with your counterparties on request. False attestation constitutes a breach of SWIFT policy and can trigger counterparty-level sanctions. Every engagement produces a documentation package structured for self-attestation support -finding records, remediation evidence, and a summary letter ready to submit or share with counterparties on request. Unlimited retests included: patch the gap, retest immediately, no additional cost.
CSCF v2025 SWIFT now requires larger institutions (Group A) to obtain independent assurance on their attestation from a qualified third party. Sprocket operates as a qualified independent third party for Group A attestation requirements. Our methodology is documented and reproducible - exactly what an independent assurance reviewer needs to sign off.
Control 1.1 Requires a secure zone to be defined around SWIFT components. Penetration testing must validate that this boundary holds under adversarial conditions. Our expert testers validate secure zone perimeters under real adversarial conditions — not checklist-based configuration review. If the boundary breaks under testing, we document how, and retest after remediation.
Control 2.6 Controls covering operator workstations require that endpoints used to access SWIFT are protected. Testing must confirm these controls are effective, not assumed. Operator workstation testing is scoped explicitly, covering phishing simulation, endpoint protection validation, and authentication control verification - the controls most often cited in SWIFT CSP gap findings.
Third-party and service bureau users Institutions using service bureaus still retain accountability for SWIFT CSP compliance. The obligation follows the SWIFT relationship, not the infrastructure owner. For institutions relying on service bureaus, Sprocket scopes testing to the connection points and controls you own so your attestation is defensible even when infrastructure is shared.
Why Continuous Testing

Benefits of continuous penetration testing for SWIFT CSP compliance

Attestation backed by evidence from today

Annual point-in-time testing tells you what your controls looked like on one day. Continuous models track your environment as it actually changes, so attestation reflects reality, not a snapshot.

No last-minute remediation

Finding a critical gap two weeks before the attestation deadline is a budget and timeline crisis. Continuous testing surfaces issues in their operational context, with time to remediate properly before the attestation window opens.

Counterparty-ready documentation

Continuous testing maintains your engagement history and produces on-demand documentation packages. When a counterparty requests your attestation evidence, you're not assembling records from three different systems.

Coverage that keeps pace

New interfaces, service bureau transitions, and infrastructure changes all affect your CSCF scope. When your environment changes, testing triggers automatically.

Independent assurance built in

Group A institutions need third-party validation, not internal sign-off. Continuous testing means no vendor change required when your assurance tier increases.

Parallel compliance value across frameworks

SWIFT CSP findings map directly to SOX ITGC, FFIEC cybersecurity assessment, and ISO 27001 Annex A Control 8.8. Continuous penetration testing outputs are structured to serve multiple frameworks from a single engagement record so your team isn't rebuilding evidence packages from scratch for every audit.

What we find

Common SWIFT CSP Findings Sprocket Surfaces

critical

Secure Zone Boundary Breakdowns

Firewall rules permitting lateral movement from general corporate networks into the SWIFT secure zone. The zone exists in documentation but doesn't hold under adversarial testing.

high

Privileged Access Without Sufficient Controls

Administrative accounts with direct access to SWIFT messaging infrastructure lack the separation, monitoring, and session management controls required by CSCF. Legitimate-looking access paths provide an attacker with direct reach to payment messaging systems.

FAQ

SWIFT CSP Penetration Testing — Frequently Asked Questions

Does SWIFT CSP explicitly require penetration testing?

Control 7.3A is a mandatory penetration testing requirement. Every SWIFT user, regardless of connectivity type, must conduct penetration testing of their SWIFT-related infrastructure annually. There is no checkbox alternative.

What does a "SWIFT-scoped" penetration test actually cover?

Scope follows your SWIFT footprint: the secure zone boundary, messaging interfaces (Alliance Gateway, SAA, SWIFTNet Link as applicable), operator workstations used to access SWIFT, authentication systems protecting SWIFT access, and any third-party connections into your SWIFT environment. Sprocket maps the test to your actual deployment.

We use a service bureau for SWIFT. Does that eliminate our CSP obligation?

No. The CSP obligation follows the SWIFT relationship, not the infrastructure. If your institution is a SWIFT member or sub-member, you are responsible for attesting to applicable mandatory controls.

What does CSCF v2025 independent assurance require, and does Sprocket satisfy it?

SWIFT's independent assurance framework requires Group A institutions to have their mandatory control attestation reviewed by a qualified external party. Sprocket operates as that independent party: we conduct the penetration test, produce documented findings, and issue engagement output your assurance reviewer can validate directly. Our methodology is documented and reproducible, which is what independent assurance reviewers need to sign off.

What happens if we find a critical issue right before our attestation deadline?

Continuous testing is specifically designed to prevent this scenario, but when it does occur, Sprocket supports accelerated remediation workflows and our expert testers can retest within days of a fix, at no additional cost. We also help your compliance team understand whether a finding constitutes a control failure for attestation purposes or a documented exception - a distinction that matters significantly for how you handle the attestation submission.

Ready to See Your Real Exposure?

Get a quote for continuous penetration testing tailored to your environment.