PCI DSS v4.0.1 and SWIFT CSP: what banks must get right

Editorial update, October 2026: this article now refers to PCI DSS v4.0.1. The PCI Security Standards Council retired v4.0 on 31 December 2024; always confirm the current version in the Council’s document library before an assessment.

Banks and payment providers usually face two attestation regimes at once. PCI DSS v4.0.1 protects cardholder data wherever cards are stored, processed or transmitted. The SWIFT Customer Security Programme (CSP) protects the local infrastructure used to send financial messages. They are different programmes with different owners, but they reward the same habits: know exactly what is in scope, isolate it, control who can reach it, and keep evidence that the controls work. This article is a high-level guide, not a substitute for the current official documents or your assessor's interpretation.

Start with scope, because scope drives cost

Under PCI DSS, every system that stores, processes or transmits cardholder data, and every system that can affect its security, is in scope. The cheapest control is the one you do not need. Reduce scope before you harden it:

• Maintain an accurate data-flow diagram and asset inventory showing where card data enters, moves and rests.
• Stop storing what you do not need, and use tokenisation or a validated point-to-point encryption solution where your business model allows.
• Document your scope and confirm it at least annually and after significant change, as PCI DSS v4.0.1 expects.

SWIFT follows the same logic through architecture types. Isolating the messaging interface, connectors and operator PCs in a dedicated secure zone shrinks the set of systems the programme applies to.

Segmentation and access

Segmentation is not mandatory in PCI DSS, but it is the main way to reduce scope, and it only counts if it is tested. A firewall rule set that nobody has validated is an assumption, not a control.

• Separate the cardholder data environment and the SWIFT secure zone from the corporate network and from the internet, with default-deny rules between zones.
• Test segmentation through penetration testing at the intervals the standard requires, and after changes.
• Require multi-factor authentication for all access into the cardholder data environment, not only for remote administrators. PCI DSS v4.0.1 strengthened this, and SWIFT expects MFA for operator and administrative access to its components.
• Apply least privilege, separate administrator accounts and review access regularly.

Logging, detection and response

Both programmes expect you to see attacks, not only block them. Centralise logs from in-scope systems, protect them from tampering, synchronise time sources and review them. PCI DSS v4.0.1 adds automated mechanisms for log review and requires the ability to detect and report failures of critical security controls. For SWIFT, pay particular attention to activity on the messaging interface, unusual message patterns and operator logons outside normal hours. Keep a tested incident response plan that covers fraud scenarios, including how and when to notify your counterparties and your regulator.

Attestation without the scramble

PCI DSS validation takes the form of a Report on Compliance or a Self-Assessment Questionnaire and an Attestation of Compliance, depending on your level and role. PCI DSS v4.0.1 also introduced the customised approach, which lets you meet an objective with a different control, provided you document a targeted risk analysis and have it validated. SWIFT requires an annual attestation against the Customer Security Controls Framework, covering mandatory and advisory controls, and this attestation is subject to independent assessment. Counterparties may ask to see your status.

• Assign a named owner to each requirement and each control.
• Collect evidence continuously, not in the final weeks.
• Track the gaps in a single remediation plan with dates and owners.
• Treat a passed assessment as a snapshot; the controls must still operate every day.

How Wethaq ICT helps

Wethaq ICT supports banks and payment providers with scope definition, segmentation design and testing, MFA and logging improvements, and readiness reviews ahead of PCI DSS and SWIFT CSP assessments. We work alongside your qualified assessor and your internal teams to close gaps in a practical order and to keep evidence ready throughout the year.