Evolution of the Swift CSP since 2016 

In an era where digitalisation has transformed the way financial institutions work, the security of financial data and transactions is more important than ever.  Following a number of security breaches at financial institutions, Swift became concerned about the security of its users. They decided to create a set of security controls and requires all its users to attest their level of compliance with these controls transparently. The CSP is continually updated to address new threats and weaknesses in the ever-changing cybersecurity landsca

SWIFT Copyright

Objectives, principles & controls

Swift has defined a set of security objectives, which are linked to seven principles and covered by the set of controls in the Customer Security Controls Framework (CSCF). The CSCF consists of 25 mandatory and 7 advisory controls, but not all controls are applicable to all architecture types: it depends on the extent to which an organisation is integrated with Swift systems.

Swift users are required to confirm their compliance with the mandatory security controls between 1 July and 31 December of each year – whether fully compliant or not!

Three Objectives and Seven Principles

• #1 Secure Your Environment 

1. Restrict Internet access & segregate critical systems from general IT environment

2. Reduce attack surface & vulnerabilities

3. Physically secure the environment

• #2 Know and Limit Access 

4. Prevent compromise of credentials

5. Manage identities and segregate privileges

• #3 Detect and Respond 

6. Detect anomalous activity to system or transaction records 

7. Plan for incident response and information sharing 

SWIFT Focus Areas

Third Party Risk Management – new mandatory control 2.8

Swift constantly monitors ongoing threats and evolutions in the cyber landscape, and adapts its CSP to meet the challenges that arise. In 2024, Swift’s focus area is Third Party Risk Management, as this topic is gaining importance both from a security and a regulatory perspective (e.g. DORA, NIS2).

Many organisations rely heavily on third-party vendors and service providers to meet various operational needs, and as a result give external parties access to systems and large amounts of data. This poses additional risks that need to be actively identified and controlled.  

What is expected for this control?

Swift has also defined an Outsourcing Agents Security Requirements Baseline, which establishes good practice on the controls to be implemented. In short, the aim of this new control is to maintain an effective third party risk management program. This includes:

• maintaining an overview of third parties (including outsourcing agents) and what components and controls they impact
• identifying critical vs. non-critical activity outsourcing, 
• performing periodic risk assessments on third parties, 
• establishing SLAs and NDAs (for critical activities)
• obtaining assurance over the security controls implemented by the third party. 

Swift users should ensure that security provisions are included in contracts with third parties, which at a minimum should comply with the CSP controls. Furthermore, roles and responsibilities should be documented.

Back Office Security – control 2.4A

In the past, the focus of the CSP was the so-called Swift Secure Zone – a segregated zone where the critical components reside. Now, Swift aims to ensure the security of the “first hop” of the back office, as it determined that significant risks exist related to the data exchange with (often legacy) back-office applications. This includes sensitive data confidentiality and integrity, unauthenticated system traffic and unauthorised access to data and systems. 

To achieve this, Swift intends to make control 2.4A Back-Office Data Flow Security mandatory in the coming years, and encourages its users to start looking into how to implement this control. For further information on this control and its implementation requirements, check out the Swift CSCF or reach out to your BDO contact person.

For the year 2024, we recommend identifying the back-office first hops and evaluating the security of existing data exchanges. Next, a gap assessment should be performed to identify the actions that will be needed to reach the desired state. Initially, Swift will focus on new flows created between the back office and Swift systems. In a second phase, legacy flows should also be protected – although these will most likely require the biggest investment, so users should not wait too long with the gap assessment and implementation.

Want to know more?