SWIFT Customer Security Programme
CSCF independent assessment, evidence, and remediation

SWIFT CSP in context: the Customer Security Programme and the CSCF

SWIFT introduced the Customer Security Programme (CSP) in 2016 in response to a series of attacks where adversaries compromised customer environments and used legitimate SWIFT credentials to move funds. CSP is the framework SWIFT uses to lift the floor of cyber hygiene across its user community. The Customer Security Controls Framework (CSCF) is the catalogue of controls every SWIFT user is expected to assess against, and the KYC-SA application on swift.com is the surface where users submit their annual self-attestation and consume the attestations of their counterparties.

The CSCF is refreshed annually. Each version (v2024, v2025, and successors) introduces or adjusts controls and may move controls between mandatory and advisory or change the architecture types they apply to. SWIFT publishes the in-force version with implementation guidance and the assessment expectations. SWIFT CSP sits alongside other financial-sector frameworks that SecPortal already covers, including the Digital Operational Resilience Act for EU financial entities, the TIBER-EU threat-led penetration testing methodology, and the CBEST intelligence-led testing framework operated by the Bank of England. SWIFT CSP is more narrowly scoped: it governs the SWIFT-related infrastructure and the operations that produce SWIFT messages, rather than the firm as a whole.

Architecture types: where CSCF scope is set

SWIFT classifies users into architecture types based on how they connect to the SWIFT network and which components they operate. The architecture type sets the in-scope CSCF controls because controls are flagged as applicable per architecture. Confirming the architecture type before the assessment begins is the structural step that prevents scope drift mid-cycle.

The CSCF principles: three objectives, seven principles

The Customer Security Controls Framework groups controls under three high-level objectives (secure your environment, know and limit access, detect and respond) and seven principles. Each principle owns a set of controls, with mandatory and advisory flags and the architecture types each control applies to. The principles below are the structure that makes the CSCF easier to navigate for assessors and assessor-led conversations with operators.

Independent assessment: the structural feature of CSP

SWIFT moved CSP from a self-attestation-only model to a model that requires an independent assessment for most user populations. The assessment can be performed by an internal team that is independent of the SWIFT-related operations or by an external assessor. The independence basis is itself part of the evidence record. The assessor walks every in-scope mandatory control, tests implementation, reviews supporting evidence, and records the compliance position with rationale. Advisory controls follow a lighter walk where the user has elected to claim them.

The evidence pack: what an assessor will look for

The independent assessment is only as defensible as the evidence behind it. The list below is the working set of artefacts a SWIFT CSP assessor will commonly request across the in force CSCF cycle. The exact list varies with architecture type, in-force CSCF version, and any deviations the user has logged, but this is the core that recurs across cycles.

Vulnerability scanning evidence and penetration test findings are usually the highest volume artefacts in the pack. The scanner result triage workflow covers how to turn raw scanner output into assessor-ready findings without losing the audit trail, and the scanner false positives guide covers the triage discipline that keeps the evidence pack focused on real issues. For the broader pentest finding workflow that feeds CSCF detection and response controls, the penetration testing workflow keeps engagement, findings, and remediation tied to a single record.

KYC-SA: annual attestation and counterparty consumption

Every SWIFT user submits an annual self-attestation through the KYC-SA application, covering the in-scope mandatory controls and the optional advisory controls the user has elected to claim. The submission carries the architecture type, the control compliance status, and a reference to the independent assessment that supported the position. KYC-SA is bidirectional: counterparties consume the attestations of their correspondents to inform onboarding and ongoing monitoring decisions, so the integrity of the submission has downstream effects on the relationships the SWIFT user maintains.

The structural risk in KYC-SA is desync between the submitted attestation and the live evidence pack: the attestation says compliant, the evidence has aged out, and the next assessor cycle finds the gap. Driving the attestation from the same workspace that holds the evidence pack closes that loop because the submission text traces back to the artefacts that supported it. Combined with the aging pentest findings research, the structural pattern across regulated frameworks is that evidence quality compounds over time only if the workflow keeps the submission and the artefact in the same record.

How SecPortal aligns to a SWIFT CSP cycle

SecPortal is built for security service providers and internal security teams running regulated assessment cycles. SWIFT CSP fits the platform model directly: the architecture type and in-scope CSCF controls drive the engagement, the assessor walks the controls on the workspace, the evidence pack lives on the finding and control records, and the attestation reflects what the workspace already says.

For the wider compliance picture, the PCI DSS framework page covers the cardholder data environment with adjacent vulnerability scanning and penetration testing expectations, and the ISO 27001 framework page covers the information security management system that often sits above the SWIFT CSP scope at the firm level. For the EU regulatory picture, the DORA framework page covers the operational resilience expectations and the threat-led penetration testing requirement that runs at least every three years for in-scope entities. For the Australian regulatory picture, the APRA CPS 234 framework page covers the prudential information security obligations APRA-regulated entities meet alongside their SWIFT-related infrastructure controls.

Practical sequencing: how to run a CSP cycle without scrambling at year end

SWIFT CSP cycles concentrate work at the end of the year because attestation and independent assessment land near the SWIFT submission window. The pattern that breaks the scramble is sequencing the work across the year rather than against the deadline.

Common deviation patterns and how to record them

Most users carry a small number of deviations from the CSCF, especially in the first two cycles after a control change or after a significant architecture migration. The defensible position is not zero deviations; it is documented deviations with a rationale, a compensating control, an owner, a remediation plan, and a retest condition. The pattern below is what the assessor reads as a mature programme.

Scope and limitations

SWIFT CSP is the framework operated by SWIFT and the assessor community. SecPortal is the workspace that holds the engagement, the controls, the evidence, and the audit trail. Submission to KYC-SA on swift.com remains an action the user takes through the SWIFT application; SecPortal holds the supporting record so the submission is grounded in the evidence pack rather than reconstructed from email and shared drives at year end.

The in-force CSCF version, the architecture type mapping, and the assessment expectations are published by SWIFT and refreshed annually. This page describes the structure of the framework and how a workspace-driven cycle plays against it; the authoritative reference for the in-force controls and the implementation guidance remains the SWIFT-published CSCF document for the cycle currently in scope.