SWIFT CSP / CSCF

Introduction: The SWIFT Customer Security Programme

The SWIFT Customer Security Programme (CSP) is a global initiative introduced by SWIFT (the Society for Worldwide Interbank Financial Telecommunication) to reinforce the security of the financial messaging ecosystem and its interconnected user community. At the heart of the CSP sits the Customer Security Controls Framework (CSCF), a mandatory set of security controls that every SWIFT user must implement and against which they must attest annually. The CSCF was created in the aftermath of a series of high-profile payment fraud attacks in which criminals compromised the local infrastructure of SWIFT users, fraudulently injected payment messages and moved funds across the network. Crucially, the SWIFT network and core messaging services themselves were not breached in those incidents; rather, the attackers exploited weaknesses in the users' own local environments. The CSCF is therefore a shared-responsibility framework: SWIFT secures its central infrastructure, and each user is accountable for securing the local systems they operate to connect to and transact over SWIFT.

This guide is written for chief information security officers, heads of payments and operations, internal auditors, and the risk and compliance teams of banks, financial market infrastructures, corporates and service bureaux that use SWIFT. It provides an auditor-grade walkthrough of the framework: what it is, who it binds, how it is structured, and a master assessment checklist that enumerates every objective, principle and control, together with the evidence an assessor should expect to see. The intent is to help an organisation prepare rigorously for its Community-Standard Assessment (CSA) and its annual attestation on the SWIFT Know Your Customer Security Attestation (KYC-SA) application.

What is the SWIFT Customer Security Controls Framework (CSCF)

The CSCF is a structured catalogue of security controls that a SWIFT user must implement across the local infrastructure that supports its connection to SWIFT. Controls are grouped under a small number of high-level security objectives, and each objective decomposes into principles, which in turn are realised by individual controls bearing unique identifiers (for example, 1.1, 2.4A, 5.1). Each control is designated either mandatory or advisory. Mandatory controls set the security baseline that all in-scope users must achieve; advisory controls represent good practice that SWIFT strongly recommends and periodically promotes to mandatory in later framework versions.

The framework is deliberately technology-agnostic and outcome-focused. Rather than prescribing a single product, each control states a risk-reduction goal (for example, restrict internet access, protect privileged accounts, detect anomalous activity) and lists implementation guidance and, importantly, an in-scope component definition describing which parts of the user's estate the control applies to. A distinctive feature is the CSCF's use of architecture types: the framework recognises that different users connect to SWIFT in different ways, and it maps each control to the components relevant to a user's specific architecture. This means two organisations may implement the same control very differently depending on whether they run a full local SWIFT stack, use a service bureau, or connect through a cloud-hosted messaging interface.

Compliance is demonstrated through an annual attestation cycle. Each year SWIFT users must self-attest their level of compliance against the mandatory (and optionally advisory) controls of the current CSCF version, and, critically, that attestation must be independently assessed. Since 2021 SWIFT has required either an independent internal assessment (by a team independent of the first line, such as internal audit or a second-line risk function) or an independent external assessment. The attestation is recorded in KYC-SA, where counterparties can be granted permission to view it, creating peer pressure and counterparty risk management around good security hygiene.

Who must comply with SWIFT CSCF

Every entity that holds a SWIFT BIC and connects to the SWIFT network to send or receive financial messages is subject to the CSP and must attest against the CSCF. The framework applies regardless of size, geography or transaction volume. The specific controls that bind a given user depend on that user's connectivity architecture, which SWIFT classifies into architecture types.

Structure of the SWIFT CSCF

The CSCF is organised as a three-tier hierarchy: a small number of overarching security objectives, each objective containing several principles, and each principle realised by one or more numbered controls. The objectives are frequently summarised by the mantra 'Secure your environment, Know and limit access, Detect and respond'. The current framework spans three objectives, eight principles and roughly thirty-two controls (the exact count varies by version as advisory controls are promoted to mandatory). The table below sets out the objective and principle structure.

Each control record in the official framework carries a rich set of attributes that an assessor must read carefully: the control identifier, the control title, whether it is mandatory or advisory, a control statement (the outcome to be achieved), the risk drivers it mitigates, the in-scope components by architecture type, implementation guidance, and, from recent versions, a set of quality-assurance sub-elements that an independent assessor uses to conclude on the control's design and operating effectiveness.

Master assessment checklist

This is the core section of the guide. It enumerates every principle and its constituent controls. For each principle there is a table stating, control by control, what an assessor should verify and the typical evidence that substantiates compliance. Control identifiers follow the CSCF convention; where a control has both a mandatory and an advisory variant, the advisory is denoted with a trailing 'A'. Confirm the exact wording and applicability against the current framework version and your architecture type.

Principle 1 — Restrict Internet Access & Protect Critical Systems from General IT Environment

Principle 2 — Reduce Attack Surface and Vulnerabilities

Principle 3 — Physically Secure the Environment

Principle 4 — Prevent Compromise of Credentials

Principle 5 — Manage Identities and Segregate Privileges

Principle 6 — Detect Anomalous Activity to Systems or Transaction Records

Principle 7 — Plan for Incident Response and Information Sharing

Scoping the assessment

Accurate scoping is foundational. The scope of a CSCF assessment is defined by the components that make up the user's SWIFT-related infrastructure and the flows that connect them. Getting this right prevents both under-scoping (leaving exploitable components unassessed) and over-scoping (wasting effort on out-of-scope systems).

1. Confirm your architecture type (A1, A2, A3, A4 or B) based on which components you own and operate versus those hosted by a service provider.
2. Inventory all in-scope components as defined by the CSCF for your architecture: messaging interfaces, communication interfaces, connectors, SWIFTNet Link/connectivity software, operator PCs, jump servers, HSMs, GUI/API access endpoints, and dedicated middleware.
3. Map the secure zone boundary and every data flow crossing it, including back-office, monitoring, backup and administrative flows.
4. Identify the general-purpose operator PCs used to access SWIFT-related applications; these are in scope even in Architecture B.
5. Include supporting infrastructure that in-scope components depend on for security, such as authentication services, PAM, secrets management, logging/SIEM and time synchronisation, where they directly enforce a control.
6. Document outsourced and third-party dependencies (service bureaux, cloud providers, managed operators) and how their controls are evidenced.
7. Freeze the scope in a scope statement agreed with the independent assessor before fieldwork begins, and record any exclusions with justification.

Implementation approach

A phased programme lets an organisation move from an unknown baseline to a defensible, independently assessed attestation. The following five phases each list core activities and the deliverables that mark completion.

Phase 1 — Scoping and architecture baseline

• Activities: classify architecture type; inventory in-scope components; draw current-state network and data-flow diagrams; identify secure-zone boundaries; catalogue third-party dependencies.
• Deliverables: approved scope statement, component inventory, architecture and data-flow diagrams, applicability matrix mapping each control to your architecture.

Phase 2 — Gap assessment

• Activities: assess current design and operating effectiveness of every applicable mandatory and advisory control; collect preliminary evidence; interview control owners; identify gaps and root causes.
• Deliverables: control-by-control gap register with risk ratings, evidence log, prioritised gap-remediation backlog.

Phase 3 — Remediation

• Activities: implement secure-zone segmentation, MFA, PAM, hardening, logging/monitoring and business controls; update policies and procedures; assign control owners; embed change control.
• Deliverables: remediated controls with configuration evidence, updated policy set, control-ownership RACI, remediation closure report.

Phase 4 — Independent assessment

• Activities: engage an independent internal or external assessor; provide evidence; walk through each control's quality-assurance elements; resolve findings; conclude on design and operating effectiveness.
• Deliverables: independent assessment report, findings and management responses, completed evidence pack aligned to each control.

Phase 5 — Attestation and continuous compliance

• Activities: submit the attestation on the KYC-SA application; grant counterparty viewing permissions as appropriate; establish continuous monitoring and an annual re-attestation calendar; track framework version changes.
• Deliverables: submitted KYC-SA attestation, counterparty sharing decisions, continuous-compliance runbook, annual re-attestation plan.

Capability and compliance scoring model

SWIFT does not publish a five-level maturity model in the manner of some frameworks; compliance is fundamentally binary at control level (compliant or not compliant, with an option to declare a control not applicable or to record an exception with a plan and target date). Nonetheless, a capability model is invaluable internally to plan improvement and to demonstrate direction of travel. The table below combines SWIFT's compliance states with a practical internal capability scale.

Alongside internal capability, record each control against SWIFT's own states: Compliant, Compliant with exception (with plan and date), Not Applicable (with justification), or Not Compliant. Advisory controls may also be marked as not attested, but assessing them is strongly recommended.

Assessment and audit approach

An independent assessment must be performed by parties independent of the first-line teams that operate the controls, whether that is an internal function such as internal audit or second-line risk, or an external firm with relevant cyber and assessment competencies. The assessor concludes on both the design and the operating effectiveness of each in-scope control.

1. Plan and confirm scope: agree architecture type, in-scope components, control applicability and the assessment period with the assessor.
2. Understand the environment: review architecture and data-flow diagrams, walk the secure-zone boundary, and confirm the component inventory is complete.
3. Assess control design: for each control, evaluate whether the implemented mechanism would, if operating, achieve the control's stated outcome across all in-scope components.
4. Assess operating effectiveness: inspect configurations, sample logs and records over the period, re-perform or observe key activities, and interview control owners.
5. Evaluate the quality-assurance sub-elements: for controls that define them, confirm each sub-element is satisfied, as these drive the compliance conclusion.
6. Test third-party reliance: examine service-provider attestations, independent assurance reports and contractual security obligations for outsourced components.
7. Document findings: record any deficiencies, their risk, and management's remediation plans with owners and dates.
8. Conclude per control: reach a compliant / compliant-with-exception / not-applicable / not-compliant conclusion for every in-scope control.
9. Support attestation: enable the responsible officer to submit an accurate KYC-SA attestation, retaining the assessment report and evidence for SWIFT-mandated retention and possible SWIFT review.
10. Establish continuous monitoring and schedule the annual re-assessment aligned to the new framework version's effective date.

Evidence request list

The following categorised evidence supports a robust assessment. Assessors should request current, dated artefacts covering the full assessment period rather than point-in-time screenshots alone.

• Governance and policy: information security policy, SWIFT-specific security procedures, scope statement, control-ownership RACI, prior attestation and assessment reports.
• Architecture and scope: network and data-flow diagrams, secure-zone definition, component inventory, architecture-type classification, third-party dependency register.
• Network and segmentation: firewall rulesets and change records, proxy/egress configuration, VLAN/subnet maps, jump-server configuration, penetration-test isolation evidence.
• Access control and identity: role/entitlement matrices, access-request and approval records, periodic recertification evidence, joiner/mover/leaver tickets, orphan-account reports, PAM logs.
• Authentication and credentials: password policy and enforcement configuration, MFA enrolment and logs, token issuance/return register, secrets-management configuration, safe/vault logs.
• System security: hardening baselines and compliance scans, patch-management reports and exception register, anti-malware coverage and update status, file-integrity monitoring output.
• Data protection: internal and external data-flow encryption configuration, certificate inventory, backup encryption, key-management records.
• Logging and monitoring: log-source inventory, SIEM retention and alerting configuration, sample investigated alerts, IDS/IPS configuration and logs, time-synchronisation evidence.
• Business controls: RMA authorisation register and reviews, payment limits/corridors, four-eyes approval configuration, transaction-monitoring rules.
• Physical security: data-centre and equipment-room access logs, CCTV coverage, HSM/token storage records, visitor logs, secure-disposal evidence.
• Vulnerability and testing: vulnerability scan schedules/reports and remediation, penetration-test reports and retests, scenario-based risk assessments.
• People and response: incident response plan and playbooks, tabletop and exercise reports, SWIFT notification contacts, security training curriculum and completion records, phishing-simulation results.
• Third parties: service-bureau/cloud provider CSCF attestations or independent assurance reports, outsourcing contracts with security and right-to-audit clauses.

Roles and responsibilities

KPIs to track

• Percentage of applicable mandatory controls assessed as compliant (target 100%).
• Percentage of applicable advisory controls implemented and attested.
• Number of controls in compliant-with-exception state and average age of open exceptions.
• Mean time to remediate assessment findings, by risk rating.
• Patch SLA adherence for in-scope systems (percentage patched within policy window).
• MFA coverage across all interactive access paths to in-scope systems (target 100%).
• Privileged-account access recertification completion rate and on-time percentage.
• Vulnerability remediation timeliness for critical/high findings on in-scope components.
• Log-source coverage and SIEM alert mean-time-to-detect and mean-time-to-respond for SWIFT-related use cases.
• Security awareness and SWIFT operator training completion rates and phishing-simulation failure rate.
• Incident response exercise cadence and number of SWIFT-relevant scenarios rehearsed per year.
• Third-party attestation coverage: percentage of in-scope service providers with current CSCF evidence.
• Attestation submitted on time each annual cycle and independently assessed (yes/no).

Readiness checklist

• Architecture type (A1/A2/A3/A4/B) correctly classified and documented.
• Complete in-scope component inventory and current data-flow diagrams produced.
• Secure zone defined and SWIFT infrastructure segregated from general IT and the internet.
• Privileged OS and application accounts controlled, monitored and minimised.
• Systems hardened to a recognised baseline and patched within SLA.
• Multi-factor authentication enforced for all interactive and administrative access.
• Least-privilege access implemented with periodic recertification and prompt leaver revocation.
• Tokens, credentials, keys and secrets stored and managed securely.
• Anti-malware, software integrity and database integrity controls deployed and monitored.
• Comprehensive logging and monitoring in place with retained, tamper-protected logs.
• RMA and transaction business controls configured to limit fraud exposure.
• Physical access to SWIFT systems and sensitive materials restricted and logged.
• Cyber incident response plan tested and SWIFT notification path defined.
• Security awareness and SWIFT operator training delivered and recorded.
• Vulnerability scanning and (advisory) penetration testing performed and remediated.
• Third-party/service-provider CSCF evidence obtained and reviewed.
• Independent assessment completed for the current framework version.
• KYC-SA attestation prepared, reviewed by the responsible officer, and scheduled for on-time submission.

Common gaps

• Operator PCs treated as out of scope, leaving the most-targeted endpoints unprotected.
• Weak or absent secure-zone segregation, with SWIFT systems reachable from the general enterprise network.
• Incomplete MFA coverage, especially on jump servers, administrative and remote-access paths.
• Privileged accounts unmanaged: shared credentials, no PAM, and no session monitoring.
• Patch and hardening backlogs on interfaces and connectors, with unmanaged exceptions.
• Insufficient logging and monitoring: key event sources missing, short retention, or no active alerting for SWIFT use cases.
• RMA relationships never reviewed and transaction business controls not configured, so fraud impact is unbounded.
• Third-party and service-bureau reliance not evidenced; no independent assurance obtained.
• Attestation submitted without a genuinely independent assessment, or based on stale evidence.
• Advisory controls ignored, causing scramble when they become mandatory in the next framework version.
• Physical protection of HSMs, tokens and printed materials overlooked.
• Incident response plan exists on paper but is never tested against SWIFT-specific fraud scenarios.

SWIFT CSCF mapped to other frameworks

The CSCF's controls align closely with established security standards, allowing an organisation to reuse existing control evidence. The table maps CSCF principles to comparable requirements in widely used frameworks. Mappings are indicative and should be validated against the specific control text of each framework.

How CyberSigma helps

Frequently asked questions

Need help with SWIFT CSCF?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.