SWIFT Customer Security Controls Policy

Customer Security Programme
SWIFT Customer Security Controls Policy
This document sets out SWIFT's Policy with regard to the customer security attestation and follow-up process.
28 August 2020
SWIFT Customer Security Controls Policy Table of Contents
Table of Contents
Preface.................................................................................................................................................3
1 Introduction...............................................................................................................................5
2 Overview....................................................................................................................................6
User Obligation to Attest .........................................................................................................6
Policy Principles ......................................................................................................................7
Key Policy Activities ................................................................................................................7
Security Attestation Application ..............................................................................................8
3 Security Attestation and Workflows.......................................................................................9
Prepare for Attesting ...............................................................................................................9
Data Contribution ..................................................................................................................10
Sharing Attestations with Counterparties..............................................................................15
Administration and Configuration..........................................................................................18
Data Retention and Deletion.................................................................................................21
4 Reporting Process..................................................................................................................22
Reporting...............................................................................................................................22
Reporting Timeline ................................................................................................................22
5 Support ....................................................................................................................................24
6 Roles and Responsibilities, Data Protection, and the Contractual Framework ..............25
Roles and Responsibilities ....................................................................................................25
Data Protection .....................................................................................................................31
Contractual Framework.........................................................................................................34
Appendix A: Glossary of Terms .....................................................................................................35
Appendix B: List of Acronyms........................................................................................................37
Legal Notices ....................................................................................................................................38
28 August 2020 2
SWIFT Customer Security Controls Policy Preface
Preface
This document describes the details of the SWIFT Customer Security Controls Policy (also
referred to as the “Policy”), including the roles, responsibilities, and process details with
regard to:
• The customer security attestation process, including the processing and use of
collected data.
• Reporting principles to foster compliance.
• SWIFT’s activities to support and improve these processes.
This Customer Security Controls Policy forms an integral part of the SWIFT Contractual
Documentation, which is in effect between SWIFT and its users.
Intended audience
This document is for SWIFT users.
Related documentation
• SWIFT General Terms and Conditions
• Customer Security Programme – Terms and Conditions
• Customer Security Programme – Overview
• SWIFT Customer Security Controls Framework (CSCF)
• KYC Security Attestation Baseline
• Shared Infrastructure Programme Policy
• Shared Infrastructure Programme Terms and Conditions
• KYC Security Attestation - User Guide (including the Grant All functionality)
• Assessing Cybersecurity Counterparty Risk - Getting Started
• Customer Security Programme - Independent Assessment Framework
• L2BA Programme
• Lite2 for Business Applications Terms and Conditions
• Knowledge Base tip 5021823 – SWIFT Customer Security Controls Framework and
KYC Security Attestation Application FAQ
• Knowledge Base tip 5023039 – Customer Security Controls Framework
Independent Assessment Guidelines and Templates
• Knowledge Base tip 5024006 – FAQ – Update to CSP Timelines
• KYC Security Attestation for Supervisors – User Guide
SWIFT-defined terms
In the context of SWIFT documentation, certain terms have a specific meaning. These terms
are called SWIFT-defined terms (for example, customer, user, or SWIFT services and
products). The definitions of SWIFT-defined terms appear in the SWIFT Glossary.
Overview of significant changes
The following table lists the main changes to the content of this document against the
previous version. The table does not include editorial changes that SWIFT makes to
improve the usability and comprehension of the document. This document is an update of
the previous version that was published in July 2019.
28 August 2020 3
SWIFT Customer Security Controls Policy Preface
New information Location

Updated provisions regarding the use of Section 6.2 Data Protection
personal data
Re-introduced the self-assessment type of Section 3.1 Prepare for Attestation
assurance
Discontinued the concept of Shared Section 3.2.2 Data Baseline
Connection Provider
Clarifications regarding SWIFT’s reporting Section 4.1 Reporting
to jurisdictional overseers and reporting of
the failure to conduct a SWIFT mandated
external assessment
Refreshed the timeline graphics to re- Section 4.2 Reporting Timeline
instate the option for self-assessment
Introduction of the Grant All functionality Throughout the document
28 August 2020 4
SWIFT Customer Security Controls Policy Introduction
1 Introduction
SWIFT has communicated to the community, the Customer Security Controls Framework
(CSCF) as part of its Customer Security Programme (CSP) to reinforce the security of the
global financial community. The CSCF describes a set of mandatory and advisory security
controls for SWIFT users. The mandatory security controls establish a security baseline for
the entire community and must be implemented by all users on their local SWIFT
infrastructure. Advisory controls are additional security good practices that SWIFT
recommends users to implement.
To create transparency around the adoption of the security controls, which allow users to
support their own cyber-risk management processes and business decision-making, SWIFT
has developed a mandatory attestation process whereby SWIFT users are required to attest
compliance against the mandatory security controls through an online portal: The KYC
Security Attestation application (KYC-SA), also referred to in this document as the Security
Attestation application. Once its attestation is published in the Security Attestation
application, the user can share it with any of its counterparties through that same
application.
The Customer Security Controls Policy applies to SWIFT users. Policies for shared
infrastructure providers are governed under separate programmes, including service bureau
entities, which are covered by the Shared Infrastructure Programme (SIP), and Alliance
Lite2 for Business Applications (L2BA) application providers, that are covered by the L2BA
Programme.
28 August 2020 5
SWIFT Customer Security Controls Policy Overview
2 Overview
User Obligation to Attest
User responsibility to attest
Each user, at least on a yearly basis, must attest compliance against all mandatory security
controls as documented in the CSCF in effect at that time.
A new version of the CSCF is typically 1 published early July, listing the mandatory and
advisory controls that will be reflected as from July of the following year in the Security
Attestation application. A new version is labelled with the year by which a user must first
attest against that version. As an example, the version 2019 of the CSCF (v2019) was
published mid-2018 and a first attestation against that version was required by end of 2019
at the latest.
Users must attest yearly, between July and December, against the version of the CSCF that
becomes effective as from January of the following year (for example, as from July 2019 for
the CSCF v2019 that became effective as from January 2020). SWIFT strongly
recommends that users attest as early as possible in the attestation window (that is,
between July and December) to avoid conflicting priorities at year end.
Each user must submit a distinct attestation for each of their published and unpublished 8-
character BICs activated 2 in the live environment.
Users must attest, irrespective of their architecture type as documented in the CSCF. For
example, users connecting through a service provider (such as a service bureau, Alliance
Lite2, Alliance Lite2 for Business Applications (L2BA) application provider, or a group hub)
must still attest. Similarly, a user making use of a third party hosting or operating all or part
of the SWIFT components the user owns, must still attest. In this case, the user has to seek
compliance results from its third party in order to fill its attestation.
New users joining SWIFT must submit their attestation prior to their activation date in the
live environment.
In case of users connecting through a non-SWIFT user group hub that is not registered
under the Shared Infrastructure Programme, the user heading the traffic aggregation
hierarchy or, as the case may be, one of the connected shareholding users must in principle
submit a distinct attestation for the PIC of the group hub. For more information about the
obligations of the user heading the traffic aggregation hierarchy, refer to the section 6.1.3
(User Roles and Responsibilities).
In the absence of an attestation being submitted for a non-SWIFT user group hub, all users
connected through that group hub must attest with architecture type A1.
Scope of the attestation
Each user must attest compliance against all mandatory security controls. Users also have
the option to attest compliance against the advisory security controls. Any attestation should
provide an accurate representation of the degree of compliance with the security controls at
the time the attestation is submitted.
Users must attest for all in-scope components in all live, back-up and disaster recovery
environments, taking into account the most encompassing architecture type. For more
details on the different architecture types and in-scope components, refer to the CSCF.
1
In exceptional circumstances, an emergency release may be required, but SWIFT expects this to be a rare occurrence.
2
If a BIC has been activated in the live environment as the sole consequence of the request for an additional test-and-training BIC
and is not used for any live operations, no attestation must be submitted with regard to that BIC.
28 August 2020 6
Figure 1: Scope of the Customer Security Controls Framework
The security controls reflect good security practice and SWIFT strongly recommends that
users implement them beyond their local SWIFT infrastructure into the broader end-to-end
transaction chain (although this is not mandatory for the purposes of the attestation
process).
Policy Principles
The SWIFT Customer Security Controls Policy is based on the following foundational
principles:
• The Policy is designed to drive improvements to security across the community, and
should be integrated into ongoing risk management within a user’s organisation.
• The approach fosters the transparency of security compliance status between users,
through sharing the attestation data, thereby increasing cyber risk management and
strengthening security.
• The attesting user retains control over sharing their published data with other users.
Any user is able to request access to users’ attestation data.
• The level of detail for information collected balances the following objectives:
− The data set is sufficiently granular for counterparty risk assessment purposes, whilst
limiting the amount of sensitive data that is collected, stored, and shared.
− The submission process does not require an undue level of effort.
• The attestation and reporting processes are designed to help users meet their
obligation to secure their local SWIFT environment, foster transparency of security
compliance, and consequently, incentivise improvements in security amongst the
community.
• The CSCF change management process is designed to ensure that the SWIFT
community has sufficient time (up to 18 months from the moment of publication) to
understand and implement any future changes to the controls requirements. Typically 3,
new mandatory controls or scope extension will be first introduced as advisory, thereby
giving all users at least two cycles to plan, budget and implement.
• Monitoring of programme quality will be evaluated by a feedback process initiated by
SWIFT.
Key Policy Activities

The Policy sets out four key activities:
3
In exceptional circumstances (like the Covid-19 pandemic), an emergency release may be required, but SWIFT expects this to be
a rare occurrence.
28 August 2020 7
1) Contribution of attestation information: All users are required to attest their level of
compliance against the mandatory security controls.
2) Sharing with other users to enable transparency between SWIFT users: Users
have the ability to share their security attestation data with other users at their own
discretion.
3) Sharing of aggregated data / league tables used for statistical comparisons with the
community.
4) Reporting activities to foster compliance: SWIFT reserves the right to report
non-compliance to counterparties or, as applicable, entity supervisors and other
supervisory authorities such as jurisdictional overseers.
Note: KYC-SA for Supervisors has been live since Q2 2020. As a result, entity
supervisors and other supervisory authorities such as jurisdictional overseers can
access their reporting information through KYC-SA for Supervisors.
Security Attestation Application

The Security Attestation application is used to collect and share users' attestation data.
Within the application, users can submit their attestation, request access to other users’
attestation data, grant access to a requesting user to their own attestation data, and view
data when authorised.
• More details on the application can be found in the chapter Security Attestation and
Workflows and in the KYC Security Attestation - User Guide.
28 August 2020 8
SWIFT Customer Security Controls Policy Security Attestation and Workflows
3 Security Attestation and Workflows

Prepare for Attesting
Assess against the Customer Security Control Framework
Before submitting an attestation through the Security Attestation application, each user must
assess against, as a minimum, all mandatory security controls as set out in the CSCF.
As from mid-2021, submitted attestations, starting with new attestations against CSCF v2021,
must exclusively be independently assessed through either:
1. Independent internal assessment conducted by a user's second or third line of
defence function (such as compliance, risk management or internal audit) or its
functional equivalent [as appropriate], which is independent from the first line of defence
function that submitted the attestation (such as the CISO office) or its functional
equivalent [as appropriate], or
2. Independent external assessment conducted by an independent external organisation
that has existing cybersecurity assessment experience, and individual assessors who
have relevant security industry certification(s).
Note that the type of assurance ‘self-assessment’ provided by the 1st line of defence remains
available but users that still select that option will be reportable as of January 2022 when the
CSCF 2021 becomes effective and mandates either an independent internal assessment by the
user's second or third line of defence function or an independent external assessment.
Those undertaking the assessment work should possess recent and relevant experience in the
assessment of cyber-related security controls as detailed in the CSP Independent Assessment
Framework (available aside to the CSCF on swift.com once logged in).
The type of assessment must be specified accordingly and confirmed within the attestation (see
the Customer Security Controls Attestation Baseline for the relevant options to be selected.
Connect to the Security Attestation application
The Security Attestation application does not require software or hardware installation on the
end-user's PC. A web browser is used to access the Security Attestation application on
www.swift.com. The URL to log in to the application is https://kycregistry.swift.com/security-
attestation.
Notes:
• To access the Security Attestation application, an end user must have a
www.swift.com account.
• To log in to the Security Attestation application, a two-step verification authentication
login is required. This means that in addition to the end-user’s e-mail address as
registered in his swift.com account and password, the end user is required to provide
an additional code which is sent through one of the following channels as per the
end-user configuration:
- A text message (sms) to the end user ’s mobile
- A voice message to the end user’s mobile phone or landline phone
- An e-mail to the end-user’s e-mail address as registered in his swift.com
account.
• The Security Attestation application provides access to attestations published and
shared by other user.
• The Security Attestation application provides access, in update mode, to the
attestation version in effect at that time. Normally, users get access from beginning of
July to the version they have to attest against by end of that year (for instance,
28 August 2020 9
beginning of July 2021 to attest against CSCF v2021). Once published, they can still
update that attestation until end of following June (for instance by end June 2022
against CSCF v2021). See also Figure 3 below.
• Before being published, an updated attestation is in draft mode and only visible by its
owner (submitter, approver, requestor and granter).
Data Contribution
Data Contribution Workflow
Overview
The contribution of data into the Security Attestation application is managed by two distinct
workflows: submission and publication.
Data must be published before it can be made visible to other users of the Security
Attestation application.
Figure 2: Data Contribution Workflow
Data submission workflow

The submission workflow concerns the creation and editing of an attestation in draft
mode prior to its submission to SWIFT for publication.
For more information on the publication process, see the Data Publication and Validity
section.
The submission process takes place either in a 2-eyes or 4-eyes mode (the latter is the
default and recommended mode), depending on the level of control required by the
organisation for content submission. In 2-eyes mode, the end user who created the draft
can submit it to SWIFT for publication. In 4-eyes mode, one end user creates the draft and
submits it for internal approval. A second end user then either approves and submits the
draft to SWIFT for publication, or rejects and returns the draft to the end user who originally
created it.
The Security Attestation application provides guidance on mandatory and optional data
fields with respect to the data submission process.
Data publication workflow
The data publication workflow is performed by SWIFT and consists, where applicable,
of controlling and validating any pre-populated data that has been edited by the user
before submission for publication. SWIFT will then either accept or reject the request
for publication issued by the attesting users.
For more information, see the section Data Publication.
28 August 2020 10
Editing data
Attesting users have the ability to update their own data published in the Security
Attestation application at any time. They can do so by:
• editing an existing published attestation, followed by a new submission to SWIFT
for publication as described above, or
• editing and submitting their attestation.
The Security Attestation application only allows editing an attestation against a specific
CSCF version during the attestation window of that version of the CSCF (see also Figure
1 below).
Earlier published version(s) of the attestation are archived in the Security Attestation
application and remain accessible for both the attesting user and counterparties that had
already been granted access to these attestation(s) and to SWIFT.
Users that have not previously been granted access to the attestation data of a
counterparty can only request access to the latest published version of that attestation.
They will not receive access to earlier archived versions.
Roles
Specific roles are required to create, approve, and submit attestation data for publication.
For more information about the roles, see 3.2.2 Data Baseline, 3.4.2 User Management
and Role Assignment, and the KYC Security Attestation For Customer Security
Programme - User Guide .
Data Baseline
Users must submit a correct and complete attestation, and use the Security Attestation
application to attest their level of compliance against SWIFT’s mandatory security controls.
In the Security Attestation application, the user completes a standardised set of security
attestation-related data, called the data baseline.
The data baseline is composed of the following elements:
• Contact details
Persons or department that counterparties or SWIFT can contact for attestation-
related questions
• Assurance type
Specifies if the attestation is supported by a self-assessment, an independent
internal assessment or external assessment
• Contact details for independent internal/external assessments
The persons or the department that counterparties or SWIFT can contact for
independent assessment-related questions.
• SWIFT infrastructure
Each user must identify and select which of the five referenced architecture types (A1,
A2, A3, A4, or B), as documented in the CSCF, matches their own SWIFT infrastructure.
The selected architecture type determines which components are in scope and which
security controls apply.
Most of SWIFT users, who have an architecture type other than A1, connect to SWIFT
using a service provider. In such a case, the attesting user must confirm or, if the data is
incorrect or unavailable, edit the pre-populated service provider type, name, and/or BIC
28 August 2020 11
or PIC code to ensure the correct service provider details are provided. Such information
is included in the attestation shared with counterparties.
Service providers support users’ connection to SWIFT. They can share partial or full
access to their SWIFT-related infrastructure. The different service providers are:
Group Hubs:
A SWIFT user or a non-user organisation connecting users within its corporate
group and as further defined by the Shared Infrastructure Programme Terms and
Conditions.
Service Bureaux:
A SWIFT user or non-user organisation registered under the Shared Infrastructure
Programme (SIP) that provides services to connect SWIFT users that are not
affiliated with such an organisation.
Service bureaux are subject to the Shared Infrastructure Programme (SIP). SWIFT
adds the SIP compliance status of the service bureau to the attestation of the user,
both at the time of publication of the attestation and at the time the attestation is
viewed.
The service bureau’s SIP compliance status is defined by reference to the full
scope of the Programme, which goes beyond security requirements and also
covers legal, financial, and resilience requirements, and the escalation procedure
applicable to service bureaux under the Programme.
For the purposes of this Policy, a service bureau is considered as compliant as long
as it is listed in the SWIFT directory of registered service bureaux.
SWIFT (covering Alliance Cloud, Alliance Lite2 and Alliance Remote Gateway):
Hosted connectivity for users operated by SWIFT.
Alliance Lite2 for Business Applications (L2BA) application providers:

Non-SWIFT user organisations registered under the L2BA Programme that provide
business application offerings, in combination with shared connectivity services, to
SWIFT users.
L2BA application providers are subject to the L2BA Programme. SWIFT adds the
compliance status of the L2BA application provider to the attestation of the user,
both at the time of publication of the attestation and at the time the attestation is
viewed by a counterparty.
For the purposes of this Policy, an L2BA application provider is considered as
compliant as long as it is listed in the SWIFT directory of registered L2BA
application providers.
Notes :
- On some occasions, users can have a separate architecture for FIN and for
SWIFTNet messaging service. In this case, users need to complete their
architecture type and/or service provider details for the infrastructure selecting
the most comprehensive Architecture Type, for example if the FIN Architecture
is assessed as an A1 and the SWIFTNet infrastructure as A3, then the user
should select A1 in the attestation.
- Regardless of the above, the scope of the security controls needs to cover all in-
scope components as set out in the CSCF, covering both the FIN and
SWIFTNet local infrastructure.
28 August 2020 12
- Users who alternate between service providers need to complete their

architecture type and/or service provider details for their main infrastructure.
This covers cases where for example, (i) a user connects through different
infrastructures located in different countries and its traffic is swapped on a
regular basis, or (ii) a switch is made to another infrastructure for disaster
recovery purposes. Also relevant in this context, the scope of the security
controls covers all in-scope components as set out in the CSCF, including all
operational and any online backup or disaster recovery infrastructures.
• Security Controls compliance details
The attesting user must confirm compliance against each applicable mandatory control.
The attesting user also has the option to confirm their level of compliance against the
advisory controls.
Notes :
- Users must update and submit a new attestation as soon as they become aware
of a change to their compliance status (for more information on the obligation to
submit a new attestation, please refer to the Contractual Framework section).
- Since English is the official language of SWIFT and its community, any comment
in free-text data fields must be in English only. Furthermore, it is not permitted to
insert comments in free-text data fields that might create confusion or be
inconsistent with the selected compliance statement, the attestation process or,
more generally, the objectives of the Customer Security Programme. While
SWIFT normally does not validate free text data fields, SWIFT reserves the right
to oppose the publication or, as the case may be, to invalidate an attestation that
does not comply with any of these conditions.
- A newly published attestation triggers a notification to counterparties to inform
them that the user’s attestation has been updated.
For more information about the security attestation-related data, see the document
Customer Security Controls Attestation Baseline.
Data Submission
By default, two end users representing the attesting user are required to adopt the following
roles in order to submit the attestation to SWIFT for publication:
Submitter
This is the end user who completes the data baseline. Contact details of the end user
must be supplied and may be used by SWIFT for follow-up in case of questions or
issues regarding the attestation. Their name and function will not be included in the
attestation shared with counterparties, unless operating in 2-eyes mode 4. This role is
typically fulfilled by the Head of SWIFT Operations. Alternatively, it can be fulfilled by
the Head of the team in charge of the independent external or internal assessment.
Approver
This is the end user who approves the submission of the attestation. The approver
must be a Chief Information Security Officer (CISO) with the necessary authority to
represent the attesting user. However, in the absence of a CISO, this responsibility can
be performed by the Chief Information Officer (CIO), Chief Risk Officer (CRO), Chief
Auditor, or another company officer or manager with a similar level of seniority who is
duly authorised to represent the attesting user. In the absence of any such a
representative, the Chief Executive Officer of the attesting user must approve the
submission of the attestation for publication. The approver’s name and function will be
included in the attestation shared with counterparties to indicate accountability for the
stated level of compliance.
4
In this situation, the submitter will also perform the role of the approver. His or her name and function will then be included in the
attestation shared with counterparties.
28 August 2020 13
Details about the User Management and Role Assignment can be found in the KYC
Security Attestation for Customer Security Programme - User Guide.
By submitting their attestation, users are deemed to warrant, represent, and undertake that
the information in their attestation is accurate, complete and up-to-date.
Data Publication and Validity

Validation and publication process
Once the user has edited and submitted their attestation, SWIFT validates whether the
completed information corresponds to SWIFT’s current internal information (for example,
whether the group hub or service bureau 8-character BIC or PIC exists and whether the
edited information matches SWIFT internal records). On successful validation by SWIFT,
the submitted attestation is published in the Security Attestation application and a
notification is sent to the attesting user in the Security Attestation application to confirm
publication (and by e-mail if the end user has configured e-mail notifications in the end user
Preferences settings).
The presence or absence of a published attestation is automatically visible to all users
accessing the Security Attestation application.
If SWIFT does not successfully validate the submitted attestation, then SWIFT notifies the
attesting user and endeavours to follow up with the user to correct the edited infrastructure
related information. The attesting user must confirm or amend all relevant information
accordingly, and re-submit.
Note : A newly published attestation (as the result of editing an existing attestation or
submitting one against the new controls) triggers a notification to counterparties, to inform
them that the user’s attestation has been updated
Validity and publication status
The Security Attestation application always indicates the date on which an attestation was
published.
The validity status of a published attestation is automatically visible to all users accessing
the Security Attestation application.
Publication status is colour-coded. A valid published attestation appears to the attesting
user in green. This means that the attestation has been successfully published and is valid.
The colour of a published attestation turns to amber when the expiry date has passed or
has otherwise been invalidated, indicating that a new attestation must be submitted.
Prior to any publication, the attestation is displayed to the attesting user in a greyed-out
colour.
Attestation validity and periodicity
Starting with the attestations submitted against the CSCF v2019, an attestation submitted
against the CSCF in effect as from the following year is typically valid until end of that
following year (and no longer limited to a maximum of 12 months). To avoid any doubt, an
attestation published in the first half of the year, and thus against the then current CSCF
version, is only valid until end of that year
To illustrate, an attestation published between July and December 2021 against the CSCF
v2021 communicated (published) mid-2020 is valid until end of 2022 by when an attestation
against the CSCF v2022 must, at last, have been published. An attestation published in
June 2022 (still against the CSCF v2021), is only valid until end 2022, by when an
attestation against the CSCF v2022 will be required.
28 August 2020 14
Note that following the SWIFT communication on CSP update on timelines, dated 18 June
2020 and describing adjustments to the CSCF cycles, SWIFT will exceptionally request that
users publish between July and December 2020, a revised attestation against the CSCF
v2019. This attestation will in all cases, cease to be valid after December 2021. Between
June and December 2021, users will be requested to attest against the CSCF v2021,
resuming the regular attestation cycle.
In the absence of a CSCF version for a specific year, users must still publish an attestation
during the second half of that specific year to confirm, on a yearly basis, their level of
compliance.
However, the attesting user must submit a new attestation earlier if any of the following
events occurs (exceptional situations):
• A change in architecture type, a change in service provider, a change in the security
controls compliance status or other similar circumstances which (likely) affect the
accuracy of a published attestation. For a list of these circumstances, see User
Roles and Responsibilities.
• An emergency update of the CSCF is required and an earlier date is specified by
SWIFT. This could be triggered in exceptional circumstances and SWIFT expects
this to be a rare occurrence.
A version history of published attestations is retained and remains visible in the Security
Attestation application to both the attesting user and to counterparties authorised by the
user to access such attestations.
Sharing Attestations with Counterparties

Access to the Attestation of Another User
Search
Users can search the Security Attestation application for published attestations of other
SWIFT users. The search is available through keywords, such as the legal name or country
of the SWIFT user, or by entering specific references, such as the active BIC or legal entity
identifier (LEI) of the attesting user. The search results show the (entity) data summary
(such as the legal name, registered address, BIC, and LEI) for the users meeting the
search criteria.
28 August 2020 15
Request access
By default, every published attestation is inaccessible to other users. Users, however, have
a general view on the presence of a published attestation and the validity status (see
section Validity and publication status in 3.2.4).
To obtain access to the attestation details of a specific user, the user must first request
access.
The access request workflow is entity-based (that is, per 8-character BIC of a user). This
means that users can send an access request on their own behalf for any and all of their
8-character BICs or, if managing a group of multiple users belonging to the same SWIFT
traffic aggregation hierarchy, on behalf of any or all 8-character BICs of other such users in
their corporate group.
For more information about group access to and use of the Security Attestation application
(including the opt-in/out functionality), see its user guide.
The access request is based on a workflow that is fully managed within the Security
Attestation application. Access to other users’ attestations must be requested through
authorised end user roles.
Grant or Reject
Users must promptly review and respond to requests for access to their attestation.
The attesting user is solely responsible for granting or refusing access (on an entity basis) to
their published attestation(s).
IMPORTANT NOTE: customers of other SWIFT group entities such as SWIFT India Domestic
Services Private Limited may also be granted access to the Security Attestation application and,
hence, could request access to the attestation of SWIFT users or otherwise request
information, data or materials from an attesting user. It should however be noted that their
access to and use of the Security Attestation application are not governed by this Policy nor the
Customer Security Programme – Terms and Conditions. Consequently, each attesting user
that would consider granting such a customer access to its attestation or supplying it with
other information, data, or materials is solely responsible for assessing beforehand whether it
has all necessary rights to do so and whether any contractual arrangements are necessary
or desirable considering in particular any resulting disclosure of confidential information or
personal data.
Once access to an attestation has been granted, it remains in place for that attestation and
any new or subsequent versions, until either the counterparty decides to
surrender/terminate their access, or the attesting user decides to revoke that access.
Granting or rejecting access requests is based on a workflow that is fully managed within the
Security Attestation application. Granting or rejecting access must be managed through
authorised end-user roles.
In order to simplify the processing of access requests, the Grant All functionality enables
those entities that opted in to have access requests from messaging counterparties
automatically granted in the Security Attestation application. The Security Attestation
application security officers may opt entities out of the Grant All functionality. In that case,
access requests must be processed manually or using the whitelist function, as outlined in
the KYC Security Attestation - User Guide.
Removing Access
Surrendering Access
A counterpart can surrender or terminate their access to a specific users’ attestation at any
time as per action 3A set out in the graphic below. After terminating access, the counterpart
can still access the attestation(s) it could access before but it will not have access to any
subsequent publications of the attestation.
28 August 2020 16
Revocation Access
An attesting user can decide to stop sharing and revoke a counterparty’s access to the
attestation data as per action 3B set out in the graphic below. From the revocation date
onwards, any subsequent publications of the attestation will no longer be accessible by that
counterparty. Past or existing attestations for which access had previously been granted will
still be accessible.
Workflow steps overview
Publication to Counterparties
Default visibility
The presence or absence of a published attestation is visible to all users accessing the
Security Attestation application.
Upon access being granted
Once authorised, the user (also referred to as a ‘counterparty’) can view the data baseline
as outlined in section 3.2.2:
• the contact person or department for the attestation
• the assessment type and name of the third-party assurance provider in the case of
external assessment
• architecture type and service provider data (including its compliance status), if
applicable
• all security controls compliance details (for all mandatory controls and, if available,
advisory controls) and user comments
• at the discretion of the attesting user, the messaging interface product name will be
shared.
• the name and function of the approver of the attestation
• the publication date
• the baseline version used for the attestation
If the attesting user connects through a service provider, then additional information will be
shared in the attestation as per 3.3.2 in order to provide a full end-to-end view of
infrastructure security.
The security controls compliance details and additional information may be used by
counterparties to inform their risk-management processes and business decision making.
For the details on the information and fields shared with authorised counterparties and
Security Attestation application users through the published attestation, see the Customer
Security Controls Attestation Baseline.
28 August 2020 17
The Download of Data

The Security Attestation application permits users to download reports with details of draft
or published version of the attestation of all entities within their entity group.
The Security Attestation application also permits users to download reports with attestation
data of their counterparties. It is not permitted to download attestation data of counterparties
other than through this controlled, password-protected and monitored data download
process. In all cases, users remain responsible for and must ensure the protection,
confidentiality and security of the attestation data of their counterparties.
For more information about the download of reports, see the KYC Security Attestation for
Customer Security Programme - User Guide.
Administration and Configuration

Entity Group Setup
In the Security Attestation application, an entity corresponds to an 8-character BIC 5 for
which a user is required to submit an attestation under this Policy. An entity group includes
all BICs for which a user must attest or, in the case of a group of multiple users belonging to
the same SWIFT traffic aggregation hierarchy, all BICs for which such users must attest.
Users wanting to change this default setup for groups of users belonging to the same
SWIFT traffic aggregation hierarchy must contact SWIFT Customer Support.
At all times, each entity group must have a minimum of two end users with the Administrator
role. For the initial setup, it will be the swift.com administrators of the user who will
automatically be granted such an Administrator role or, in the case of a group of multiple
users belonging to the same SWIFT traffic aggregation hierarchy, the swift.com
administrators of the user heading the traffic aggregation hierarchy.
The role of the Administrator is always defined at the entity group level. This means that, for
an entity group composed of more than one entity or more than one user, this role cannot
be limited to a subset of entities or users in the group.
Business roles (such as Submitter, Approver, Requester, Granter), as opposed to the
Administrator role, can be defined at the level of a specific entity (that is, 8-character BIC).
This means that, for an entity group composed of more than one entity or user, an end user
with a business role can be assigned to a subset of entities and/or users in the group.
5
Or 8-character PIC in the case of a non-SWIFT user group hub
28 August 2020 18
User Management and Role Assignment

Overview
Users are responsible for appointing at least two Administrators to manage their own end
users and group settings.
The user must ensure that:
• Their Security Attestation application Administrators have the necessary authority to
enable their endusers to use the Security Attestation application and perform their
roles and responsibilities on behalf of the user and other users (if any) belonging to
the same SWIFT traffic aggregation hierarchy, including but not limited to:
- assign and manage other end user roles (for Administrators)
- submit data
- approve data submission for publication
- request/surrender access to view other users’ attestation data
- grant/reject/revoke access to other users
- view the attestation data of other users
• This Policy and other relevant documentation is available to all their end users .
• Their end users use the Security Attestation application in compliance with this
Policy and other relevant documentation.
Privileges in the Security Attestation application are granted on a role-based access model.
The Security Attestation application Administrators of the user are responsible for exercising
due care in assigning appropriate roles to individual end users they manage, in accordance
with all relevant internal policies and procedures applicable within their organisation. For
example, this includes a regular review of all end user accounts and prompt revocation of
privileges when an end user changes role or leaves the user organisation.
The user administration can be configured in a 2-eyes or 4-eyes mode.
Administrator role
The Administrator of the users is responsible for:
• inviting new end users with a valid swift.com account
• assigning and managing their roles in the Security Attestation application
• assigning and managing the scope of entities in the entity group
• reviewing regularly all end user accounts and their entitlements
• managing entity group settings such as the 2-eyes or 4-eyes data submission
mode, 2-eyes or 4-eyes user administration, enabling or disabling counterparty
notifications, and so on.
Security Attestation application roles
Role Description
Administrator Manages end users, roles, and configures Security Attestation
application group settings as defined previously. Such a role must be
assigned to at least two end users and applies to all entities in the
group.
Approver • Reviews and approves attestations submitted by the Submitter
28 August 2020 19
Role Description
(if 4-eyes
• Usually the user's CISO, but may be a designated executive,
principle is
officer or manager as described in section 3.2.3 Data Submission
applied)
Granter Authorises counterparties to access own entities' data. Such a role
must be assigned to at least one end user
Requester Requests access to a counterparty’s attestation
Security Officer • Download sensitive data reports.
• Select Opt-in or Opt-out in the context of the Grant All
functionality
• Global role. The security officer role applies to all entities of the
group.
SWIFT recommends that users grant this role to the Executive
(typically, the CISO or CRO) responsible for the information
security risk management within the user organisation.
Such a role should be assigned to at least one end user.
Submitter • Creates and edits the attestation. Such a role must be assigned to
at least one end user
• Submits an attestation for validation and publication to SWIFT (if
2-eyes principle is applied)
• Submits an attestation for approval to the Approver (if 4-eyes
principle is applied)
Viewer Can view drafted and published attestation for own entities and the
attestation data of other users who have granted access to their
attestation
End users
The creation of an end user follows a three-step process:
1) The Administrator invites the new end user to join the Security Attestation application
through dedicated administration screens.
2) The Administrator assigns the new end user one or several Security Attestation
application roles (may include the Administrator role).
3) The Administrator assigns the new end user a scope of entities in the entity group.
An end user always has the same role(s) for all of the entities that he or she is assigned
to. For example, it is not possible to be Submitter for entity A and Granter for entity B. It is
possible to be both Submitter and Granter for both entities A and B.
Any user (except the Administrator and the Security Officer) can by default see the
attestation data of the entities they are assigned to within their own group of entities.
Reporting Tools
A number of predefined reports related to the use of the Security Attestation application
are available for download. Out of the exhaustive list available in the Security Attestation
application User Guide, the following reports can be found:
• user role assignments report: a list of end users, their roles, and assigned entities
• missing roles report: a list of entities missing end users with essential roles (that is,
Submitter, Approver, or Granter role)
28 August 2020 20
• data access requests received: a list of entities that requested access to a user’s
attestation data
• data access requests sent: a list of access requests sent to counterparties
• data contribution activity log: a log of activities performed by end users that belong
to the same entity group. For example, the log contains the draft creation date, the
draft submission date, and the publication date
• My entities and counterparties status and details reports: provide compliance status
and controls details for your own and accessible counterparties attestations. Such
reports can only be requested by an end user with the Security Officer role.
Considering the sensitivity of such information, those reports are passphrase
protected.
Data Retention and Deletion

Data content
The Security Attestation application retains the information of an entity (or BIC) until the
attesting user ceases to be a SWIFT user. As of that moment, the information is deleted in
accordance with the following data retention and deletion process.
• Attesting user that ceases to be a SWIFT user and, consequently, is removed from
the Security Attestation application:
Information remains available to counterparties for 110 days as from the loss of
SWIFT user status and permanently deleted from the Security Attestation
application afterwards.
90 days before deletion, the application notifies the counterparties that have access
to this entity that the entity's information will be deleted.
• Changes relating to individuals listed in the Security Attestation application:
When an attesting user wants to modify the data fields related to individuals listed in
a published security attestation (such as the contact person for the attestation), the
user must edit the published version by creating a new version of the attestation.
The new version of the attestation must be submitted and published in the
application for the changes to take effect. The previous published version of the
attestation is archived in the application, which can still be consulted by
counterparties who already had access to the entity’s data. The archived data is
only permanently deleted from the application when the attesting user ceases to be
a SWIFT user and, consequently, is removed from the application, as described
above.
Back-up retention
For resiliency and security purposes, SWIFT keeps back-ups of the Security Attestation
application. Such back-ups are stored on SWIFT back-up servers until a maximum of 6
months after the data content has been deleted from the application.
Usage statistics
SWIFT reserves the right to compute and retain statistical information on the adoption and
usage of the Security Attestation application for reporting activities, product development,
support, account management, and other legitimate internal purposes. Such data will
always be aggregated and will not allow the singling-out of individuals whose personal data
is contained in the application. SWIFT may, for historical purposes, retain such statistical
information as long as it offers the Security Attestation application.
28 August 2020 21
SWIFT Customer Security Controls Policy Reporting Process
4 Reporting Process
Reporting
To encourage compliance with the mandatory security controls and this Policy, and
without prejudice to other rights and remedies available to SWIFT under the SWIFT
Contractual Documentation, SWIFT reserves the right to report to entity supervisors and
other supervisory authorities such as jurisdictional overseers the status of users failing to
comply with this Policy or other circumstances, including as applicable:
• late submission or the absence of an annual attestation in the Security Attestation
application
• attested non-compliance against one or more mandatory security controls
• non-compliance of the service provider of the user. That is:
− for group hubs:
 late submission or the absence of an annual attestation in the Security
Attestation application
 attested non-compliance against one or more mandatory security controls
− for service bureaux or L2BA application providers:
 non-compliance against the mandatory compliance level in place at the time
• non-compliance with a request from SWIFT to conduct a SWIFT mandated external
assessment.
SWIFT also reserves the right to provide regular status updates on users’ attestations to
SWIFT overseers or other supervisory authorities such as jurisdictional overseers.
Summary level information will be shared including the following statistics (excluding
customer names):
• the number of late and non-attesting users per country or region, and SWIFT user
category
• for submitted attestations, aggregated statistics on control adherence (in line with
response options) per, as the case may be, control, industry market sector, country
and SWIFT user category.
For the purposes of encouraging adoption of the SWIFT Customer Security Controls
Framework (CSCF) and attestation process, SWIFT National Member Groups (NMGs) and
National User Groups (NUGs) may receive similar summary reporting for their country.
Reporting Timeline
Supervised entities
SWIFT’s reporting right to supervisors and other supervisory authorities such as
jurisdictional overseers covers those users that have not published an attestation on time or
that have failed to attest full compliance with all mandatory security controls in a timely
manner or that connect through a non-compliant service provider or that did not comply in a
timely manner with a request to conduct a SWIFT mandated external assessment.
SWIFT also reserves the right to share the list of entity supervisors for the user with other
Any such reporting is limited to the name of the user concerned and the related 8-character
BIC. Any additional information will need to be obtained on a bilateral basis between the
supervisor or other supervisory authority concerned and the user concerned.
28 August 2020 22
SWIFT Customer Security Controls Policy Reporting Process
Reporting to supervisors and other supervisory authorities such as jurisdictional overseers

is intended to take place at regular intervals (typically, every 6 months).
Figure 1: CSCF Change Management Process, Security Attestation application,

attestation windows and Reporting Timelines taking v2019 until v2022 as examples
Messaging counterparties
SWIFT reserves the right to report the same circumstances and data to messaging or other
counterparties of the users.
This reporting will be available to the counterparties who have been granted access to the
attestation data of the user concerned.
SWIFT overseers
SWIFT will provide regular (typically, every 6 months) status updates (at a summary level)
on users attestation to SWIFT’s overseers.
SWIFT National Member Groups (NMGs)/National User Groups (NUGs)
Reporting to NMG and NUGs will occur on an ad hoc basis (at a summary level).
28 August 2020 23
SWIFT Customer Security Controls Policy Support
5 Support
Support
SWIFT is the single point of contact to report all problems and queries that relate to the use of
SWIFT support can also be contacted to answer queries about the definition of the security
controls in the SWIFT Customer Security Controls Framework (CSCF) document. However,
SWIFT cannot and will not validate or otherwise confirm user compliance with the security
controls. The responsibility for attesting compliance against the mandatory security controls
fully lies with each user. Precise implementation of the security controls must be assessed by
each user taking into account the specific attributes of their own architecture type and local
configuration, and can therefore only be fully determined by the SWIFT user itself. Users
requiring specific support to assess, remediate and provide assurance against the security
controls can engage a third party cyber-security service provider. SWIFT provides a directory
of such service providers for information purposes only.
Individuals within a customer organisation must register to use the Support service.
Related information
For more information about Support services, please refer to the service description related
to the applicable support package.
28 August 2020 24
SWIFT Customer Security Controls Policy Roles and Responsibilities, Data Protection, and the
Contractual Framework
6 Roles and Responsibilities, Data Protection,

and the Contractual Framework
Roles and Responsibilities
Introduction
To conduct business over the SWIFT network, users need to have a commercial
relationship with other SWIFT users. Users shall establish such relationships taking into
account multiple criteria. In addition to obvious commercial considerations, these typically
include KYC and sanctions/AML compliance, operational risk, and fraud.
Cybersecurity is also an important consideration in establishing such relationships. As with
the other criteria, it requires evaluation by each user of each of their business
counterparties. Each user shall therefore be responsible for applying their own risk
assessment and measuring this against their own risk appetite.
Each user is ultimately responsible for performing a proper risk assessment, and will
typically use various sources and categories of information to do so.
SWIFT, as a member-owned cooperative, has developed various initiatives under the
SWIFT Customer Security Programme for the collective benefit of its user community, such
as the SWIFT Customer Security Controls Framework (CSCF) and this Policy, which are
designed to help the SWIFT user community improve cybersecurity and Assessing
Cybersecurity Counterparty Risk - A Getting Started Guide to facilitate cybersecurity risk
assessment by and amongst users directly.
SWIFT’s roles and responsibilities for these initiatives are separate from SWIFT’s roles and
responsibilities as provider of SWIFT services and products. In the context of the CSCF and
this Policy, which are part of the Customer Security Programme, SWIFT is acting as a
facilitator of standards and transparency regarding the cybersecurity compliance status of
users. Users must attest against the security controls set out in the CSCF. While SWIFT
reserves the right to report failures to comply therewith, each user remains solely and
exclusively responsible for any reliance thereupon and, more generally, any decision to
exchange or stop exchanging messages or files with another user, and defining and
implementing appropriate supporting controls and other arrangements.
SWIFT’s Roles and Responsibilities

General
SWIFT manages and supports the CSCF, the Security Attestation application, and this
Policy in all material respects as described in the Customer Security Controls Framework
document, this Policy, and other SWIFT Contractual Documentation.
Nothing in the CSCF, the Security Attestation application, or this Policy shall be construed
or interpreted as SWIFT taking or accepting any responsibility or liability for users’ roles and
responsibilities as set out in this Policy or elsewhere in the SWIFT Contractual
Documentation, including but not limited to the obligation for each user to duly secure their
local environment, independently determine the security of any relevant service provider or
to perform a proper risk assessment, and to define and implement appropriate controls and
other arrangements before any decision to exchange (or stop exchanging) messages or
files or, more generally, do business with another user.
28 August 2020 25
No judgemental activities
Each user acknowledges and agrees that the CSCF, the Security Attestation application
and this Policy, including all information, data, or materials made available in connection
therewith:
(a) are made available and managed by SWIFT for the sole purpose of helping its user
community improve cybersecurity and facilitating cybersecurity risk assessment by and
amongst users directly
(b) should not be interpreted or construed by users or any other recipient as SWIFT
representing or undertaking any task or activity involving a judgment or decision on any
user’s account or otherwise substituting for enquiries, procedures, measures, advice, or
other activities which ought to be undertaken by or for a user or any other third party;
SWIFT shall not:
(a) make any representation or warranty (express or implied) to any user or any other
person with respect to any information, data, or materials made available through or in
connection with the CSCF, the Security Attestation application, or this Policy, whether at
the date of its availability or at any other time. Without limitation to the foregoing, SWIFT
expressly disclaims all representations and warranties that the information is accurate,
complete, up-to-date, or reliable for any purpose whatsoever
and
(b) owe or assume any liability or responsibility - whether in contract, tort, or otherwise - to
any user or any other person for any decision or omission based on or, more generally,
any reliance on any information, data, or other materials available through or in
connection with the CSCF, the Security Attestation application, or this Policy.
Validation of information submitted by users
SWIFT validates the information, data, or other materials available through the Security
Attestation application only if and to the extent expressly documented in this Policy, in which
case any such validation is performed in accordance with the principles set out in this
Policy.
It is important to note that SWIFT’s validation is based on its then-current internal
information, without conducting any special investigation or diligence to add to such
information. Any such validation does not waive or otherwise affect the ultimate
responsibility of the attesting user for the contents of the attestation as set out in the User
Roles and Responsibilities section.
Information pre-populated or added by SWIFT
If SWIFT pre-populates or adds information to the attestation, any such information is pre-
populated or added and, as applicable, maintained by SWIFT as documented in and in
accordance with this Policy.
The fact that SWIFT may pre-populate information in the attestation does not waive or
otherwise affect the ultimate responsibility of each attesting user for the contents of the
attestation as set out in the User Roles and Responsibilities section.
Updates
SWIFT may need adjust the CSCF or this Policy by publishing a new version of the relevant
documentation. While updates will normally follow an annual release schedule, SWIFT may
be forced to make such adjustments outside that schedule (typically, to reflect changes to
the cybersecurity landscape). Any interim changes to the policy or the CSCF will be
communicated appropriately to customers (for instance through FAQs and/or newsletters
before, when relevant, being included in the next version or by updating the Security
Attestation application Baseline or User Guide). Users must ensure they always refer to the
latest available version of the relevant documentation.
28 August 2020 26
Quality assurance
It is important for SWIFT to be able to monitor and gather feedback on the quality and
effectiveness of the CSCF, the Security Attestation application, or this Policy. Different
processes are intended to assist SWIFT in this regard including:
• As primary inputs, SWIFT reserves the right to:
- use data submitted by attesting users in the Security Attestation application and
other information in SWIFT’s possession related to users’ use of SWIFT
services and products;
- require users to participate in specific quality assurance activities (typically,
surveys, interviews, …), or to provide SWIFT with additional information, data or
materials as is reasonably required to further substantiate their attestations.
• SWIFT also reserves the right to require users to deepen investigation or to seek
additional independent assurance (for example, to conduct a SWIFT-mandated
external assessment) regarding the accuracy of their attestations and, as
applicable, to correct their attestation accordingly. For more information, see in
particular the Customer Security Programme – Independent Assessment
Framework (available aside to the CSCF on swift.com once logged in);
• SWIFT may decide to use outputs from the quality assurance activities to issue
specific communication towards users and/or to modify the CSCF, the Security
Attestation application, or this Policy;
• SWIFT may provide SWIFT overseers, supervisors and other supervisory
authorities such as jurisdictional overseers and the SWIFT community with updates
about the quality assurance activities on an anonymised basis.
Quality assurance activities are intended to cover groups or segments of users across the
broader community of SWIFT users as opposed to individual users. Groups or segments of
users will typically be selected based on reasonable indications of quality or effectiveness
concerns particularly in terms of overall understanding of the security controls or the
veracity of attestations across the specific groups or segments of users.
SWIFT’s right to use the attestation data
SWIFT reserves the right to use data submitted by attesting users in the Security Attestation
application and any other information, data or materials supplied by or for a user in
connection with this Policy for purposes relating to the provision, security (including forensic
investigations), use or support of SWIFT services and products, or for SWIFT governance
purposes.
User Roles and Responsibilities

General
Each user is automatically granted access to the Security Attestation application. Users
must access and use the Security Attestation application in accordance with this Policy, The
KYC Security Attestation for Customer Security Programme - User Guide and other SWIFT
Contractual Documentation. In using the Security Attestation application and conducting its
business, the user must always exercise due diligence and reasonable judgment, and must
comply with good industry practice and all relevant laws, regulations, and third-party rights
(including the rights of the attesting users).
In the case of a group of multiple users belonging to the same SWIFT traffic aggregation
hierarchy, such an access is granted by default through the user heading the traffic
aggregation hierarchy. Users wanting to change this default setup must contact SWIFT
Customer Support.
The user that accesses and uses the Security Attestation application on behalf of other
users belonging to the same SWIFT traffic aggregation hierarchy must assume any
28 August 2020 27
obligations, roles and responsibilities of each such user as if it were the attesting user,
including but not limited to any obligation to attest and to supply accurate, complete and up-
to-date information, as well as keep apprised of changes that could require an updated
attestation from such a user. Such a user represents and warrants that it is duly authorised
by each such a user to access and use the Security Attestation application on behalf of that
user, and will hold SWIFT harmless for any adverse consequences or liabilities SWIFT may
incur towards other users (including other users belonging to the same SWIFT traffic
aggregation hierarchy) or any other person in that context.
Compliance with the CSCF and this Policy does not waive or otherwise affect the obligation
for each user to duly maintain at all times the confidentiality, integrity and availability of
traffic, message, configuration and other data in their local environment or any other
obligations, roles and responsibilities applicable to it as set out in the SWIFT General Terms
and Conditions or other SWIFT Contractual Documentation.
Attestation
Each user is solely and exclusively responsible for:
• the timely submission of complete attestation(s) in accordance with the principles
set out in this Policy
• ensuring it has all rights and permissions necessary so that all information, data or
other materials supplied through or in connection with the Security Attestation
application can be stored, used, and made available by SWIFT as set out in this
Policy, including all necessary permissions from third parties when such
information, data, or other materials originate from or relate to a third party
• ensuring all information, data or other materials supplied through or in connection
with the Security Attestation application are accurate, complete, and up-to-date
• verifying and validating any and all information pre-populated by SWIFT (for
example, the identification of the user and their BICs or information about the user’s
infrastructure or connection to SWIFT or the list of entity supervisors for the user). If
the information pre-populated by SWIFT is not correct, the user is solely
responsible for amending it, and if unable to do so, contacting SWIFT Customer
Support to request a correction, in which case the verification and validation
obligations of the user remain fully applicable.
If SWIFT does not pre-populate but rather adds information and, as applicable,
maintains information in the attestation (typically, the information about the SIP
compliance status of a service bureau), the user’s verification and validation obligations
do not apply in respect of that information.
As a general principle, SWIFT does not assume and expressly disclaims any responsibility
or liability for any user failing to timely submit an attestation or to supply accurate, complete
and up-to-date information or, more generally, failing to comply with any obligation
applicable to it under this Policy or other SWIFT Contractual Documentation.
Obligation to submit a new attestation
Users must update and submit a new attestation before the expiry of the validity period in
any of the following circumstances:
• any change of architecture type
• any change of service provider (for example, a change of service bureau, or group
hub)
• the user becomes aware that the information in the attestation, in whole or in part, is
no longer accurate, complete, or up-to-date (excluding any information added and
maintained by SWIFT as expressly documented in this Policy or other relevant
documentation), for example, a change in contact information or a change in
security control compliance status
28 August 2020 28
• any change to the traffic hierarchy of an entity in which case the user must contact
SWIFT Customer Support
• the user starts use of a new BIC falling within the scope of the attestation obligation
(see the section User Obligation to Attest).
The update must be completed as soon as possible after the user becomes aware of the
circumstances requiring an update of their attestation and, it should not be later than three
months after the circumstances requiring such an update first occurred.
Users becoming aware of circumstances likely to require the submission of a new
attestation but who are not yet in a position to do so may in the meantime contact SWIFT to
invalidate their current attestation. SWIFT also reserves the right to invalidate an
egregiously incorrect attestation.
Obligation to review access requests and contact details
To leverage the Security Attestation application when conducting cybersecurity risk
assessments, users must promptly review and respond to attestation access requests.
While at least one end user must have been assigned the granter role, additional granters
should be defined to answer access requests within the recommended period of six
business days. Users can also opt in for the Grant All functionality, in which case access
requests from messaging counterparties are automatically accepted.
In order to facilitate and speed up users reach out, in case of security related incidents with
actual or potential impact to them or other users , contact details of the user (operational,
business or for the attestation itself) must be regularly reviewed and kept up-to-date.
With the introduction of the Grant All functionality, users that opt in are addressing this
obligation to accept or reject requests coming from a messaging counterparty as such
requests are automatically accepted. Facilitating and supplementary nature of the CSCF,
the Security Attestation application, and this Policy
While SWIFT encourages users to leverage the CSCF, the Security Attestation application,
and this Policy to improve their cybersecurity and to use inter alia the information, data, or
other materials so made available when conducting cybersecurity risk assessments, each
user remains solely and exclusively responsible for assessing whether the CSCF, the
Security Attestation application, and this Policy are fit for these purposes. Nothing in the
CSCF, the Security Attestation application, or this Policy shall be construed or interpreted
as any delegation, sub-contracting, or any other transfer to SWIFT of the performance by
any user of their own security-related or other obligations, roles, and responsibilities.
Without prejudice to the generality of the foregoing, and with respect to both their own
cybersecurity and the performance of cybersecurity risk assessments, each user must:
• retain the necessary expertise and staff and continue to make all necessary
judgements and take all appropriate decisions
• ensure that appropriate risk management, monitoring, and control procedures
continue to apply
• maintain appropriate contingency plans covering (without limitation) both planned
and unplanned) unavailability of the Security Attestation application.
Beyond the Security Attestation application, users are encouraged to communicate and
exchange further information, data or materials amongst themselves directly.
User’s operational responsibilities

At the operational level, the user must take the following actions:
• give SWIFT such an assistance as is reasonably required to ensure the smooth
performance of the CSCF and this Policy.
28 August 2020 29
• in case of problems relating to or in connection with the Security Attestation

application, the user must:
- notify the SWIFT Customer Support Centre promptly of the problem
- assist SWIFT in identifying, investigating, and resolving the problem
- promptly correct the problem if it is the user’s responsibility to do so, and notify
SWIFT when it has been resolved
- respond correctly and promptly to any actions requested, recovery, or fallback
procedures initiated, or directions given by SWIFT to mitigate or resolve the
problem, and revert to normal operation conditions when the problem is
resolved.
Non-SWIFT user group hub
The user submitting an attestation for a non-SWIFT user group hub must procure the
performance and observance by the group hub with any obligations, roles, or
responsibilities as if the group hub were a user, including but not limited to any obligation to
supply accurate, complete, and up-to-date information, data, or other materials.
Confidentiality
Any information, data and/or materials (the “Confidential Information” ) that a user (the
‘Disclosing User’) shares or otherwise permits to make available to another user (the
“Receiving User”) through or in connection with the Security Attestation application shall be
considered as confidential and proprietary to the Disclosing User. The Confidential
Information does not include information the Receiving User can prove by written records is
in the public domain through no breach of their obligations of confidence.
The Receiving User must ensure the protection, confidentiality, and security of the
Confidential Information using the same standard it employs to safeguard their own
information of like kind, but in no event less than a reasonable standard of care in
accordance with good industry practice.
The Receiving User shall use the Confidential Information for no other purpose than
conducting cyber-risk assessments in connection with their use of SWIFT. Any other use
requires the prior written approval of the Disclosing User.
The Receiving User shall neither directly nor indirectly disclose or permit any Confidential
Information to be made available to any third party other than their employees, directors,
agents, subcontractors, or professional advisers without prior written authorisation from the
Disclosing User.
Subject to the foregoing, the Receiving User undertakes that it will only disclose any
Confidential Information on a strict need-to-know basis, always subject to the following:
(1) Prior to disclosing any Confidential Information, the Receiving User will:
(a) Inform the recipient of the restrictions as to use and disclosure of any such Confidential
Information; and
(b) Ensure that the recipient is bound by a confidentiality undertaking or obligations of
confidence, which protect such Confidential Information to at least the extent that it is
protected under this provision.
However, the Receiving User shall not be deemed to be in breach of their obligations of
confidence if it discloses or otherwise shares Confidential information in response to a bona
fide subpoena or other lawful process by a court or regulatory, supervisory, or governmental
authority of competent jurisdiction, provided however that the Receiving User shall, if and to
the extent permitted by applicable law, (1) notify the Disclosing User and SWIFT without
delay of any such a process; (2) use reasonable efforts to maintain the protection,
confidentiality, and security of the Confidential Information; and (3) co-operate with and
28 August 2020 30
assist the Disclosing User so as to allow it to seek any legal remedies it may deem
appropriate to protect such Confidential Information.
The Receiving User acknowledges and accepts that the obligations of confidentiality set out
in this provision shall be deemed to be also for the benefit of, and accepted by, the
Disclosing User.
Each Disclosing User acknowledges and agrees that SWIFT shall not owe or assume any
liability or responsibility - whether in contract, tort or otherwise - to the Disclosing User or
any other person for any failure by a Receiving User to protect any Confidential Information.
Any rights or remedies available to the Disclosing User under this Policy or otherwise must
be enforced by the Disclosing User against the Receiving User directly.
The obligations of confidentiality of SWIFT regarding the data submitted by attesting users
in the Security Attestation application and any other information, data or materials supplied
by or for a user in connection with this Policy are as set out in clause 11.2 of the Customer
Security Programme – Terms and Conditions or this Policy (typically, SWIFT’s reporting
rights as set out in Chapter 4). SWIFT shall also be permitted to provide entity supervisors
with their list of supervised users and to disclose the list of users’ entity supervisors to other
Customer Testing
Users must not conduct any performance or vulnerability tests on the Security Attestation
application unless expressly permitted in the SWIFT Customer Testing Policy. If users
believe they have identified a potential performance or vulnerability threat, they must
immediately inform SWIFT support thereof and treat all related information, data, or
materials as SWIFT confidential information.
Data Protection
Protecting personal data is very important to SWIFT, as the confidentiality of data touches
upon the core of its activities.
The Security Attestation application Baseline and User Guide describes how SWIFT collects
and processes personal data in the context of the Security Attestation application, as well as
the roles and responsibilities of both SWIFT and the users in this context.
Purposes for which SWIFT will process Personal Data

SWIFT will process the personal data for the following purposes:
• Maintaining and making the Security Attestation application available to users as

set out in this Policy, which include:
- Collecting the personal data (see the Security Attestation Baseline for more
information on what Personal Data are collected) through the attestation form
- Making personal data available to counterparties of the user such as data
relating to the contact person for the attestation, the name and title of the person
who approved the submission of the attestation, as well as the identification and
contact details (such as first and last names, company, job title, direct phone
number and e-mail) of the contact person (if any) (i) at the company the user
engaged to conduct an independent external assessment or (ii) at the internal
department the user engaged to conduct an independent internal assessment
- Contacting the attesting user for any questions relating to the attestation
• Contacting users in case of security related incidents with actual or potential impact
to them or other users, using for instance the 24/7 SOC or business contact details
• Inviting individuals to events organised by SWIFT (such as Sibos, SOFE)
discussing matters relating to the Customer Security Programme or, more
28 August 2020 31
generally, (cyber-)security matters. Although this purpose relies primarily on

SWIFT’s legitimate interest, marketing communication may sometimes require the
individual’s consent. In that case, SWIFT will use that consent as legal basis and it
is each individual’s right to withdraw its consent at any time by addressing a written
request to SWIFT (see below). Note that withdrawing the consent will not affect the
lawfulness of the processing that was based on consent before its withdrawal.
• Allowing or facilitating any security-related communications between SWIFT and
the user
• More generally, when required for the performance of SWIFT's roles,
responsibilities, rights and remedies in connection with this Policy or the Customer
Security Programme – Terms and Conditions
SWIFT (which is the trade name of S.W.I.F.T. SC, a Belgian cooperative company, with
registered office at Avenue Adèle 1, 1310 La Hulpe, Belgium, and registered in the
company register of Brabant wallon with number RPM 0413.330.856) processes the
personal data in the Security Attestation application as a data controller under the
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April
2016 on the protection of natural persons with regard to the processing of personal data
and on the free movement of such data, and repealing Directive 95/46/EC (General Data
Protection Regulation (GDPR).A data controller under the GDPR is the company that
determines the purposes and means of the processing of personal data.
Specific SWIFT Responsibilities regarding Personal Data

Operation of the Security Attestation application
IP addresses
SWIFT will process IP addresses used when accessing the Security Attestation application
in accordance with its Privacy Statement, available at the bottom of all pages on
www.swift.com.
Cookies
SWIFT will use cookies when accessing the Security Attestation application in accordance
with its Cookie Policy, available from its Privacy Statement on www.swift.com.
Data security
SWIFT protects personal data submitted in the Security Attestation application against
accidental or unlawful destruction, accidental loss, alteration, and unauthorised disclosure
or access.
Therefore, SWIFT monitors and records the traffic, both incoming and outgoing, in order to
preserve the security, integrity, and availability of our infrastructure. These data are kept for
up to one year.
Users of the Security Attestation application acknowledge and agree that SWIFT cannot
ensure the security of the personal data on their own systems or during transmission over
the Internet. In this regard, SWIFT advises users to take every possible precaution to
protect personal data stored on their own systems as while in transit over the Internet.
Personal data breach notification
In case of a breach of security leading to the accidental or unlawful destruction, loss,
alteration, unauthorised disclosure of, or access to, personal data submitted to the Security
Attestation application, SWIFT will notify the personal data breach to the
28 August 2020 32
Belgian Data Protection Authority and to the individuals concerned, if and as required under
the GDPR or any other relevant data protection legislation.
Rights of individuals
SWIFT will, under the conditions of the GDPR, permit individuals whose personal data was
submitted to the Security Attestation application to:
• exercise their access rights and obtain the correction or deletion of their personal
data, where appropriate
• object to the processing of their personal data on compelling legitimate grounds or
for direct marketing purposes.
Individuals may exercise the above rights by sending a written request with a proof of their
identity to S.W.I.F.T. SC, to the attention of the Privacy Officer, Avenue Adèle 1, 1310 La
Hulpe, Belgium, or by e-mail to privacy.officer@swift.com.
Individuals also have a right to lodge a complaint with the supervisory data protection
authority in their country of residence, place of work, or where an incident took place. In
Belgium, the data protection authority is:
Belgian Data Protection Authority

Rue de la Presse 35, 1000 Brussels
Phone: +32 (0)2 274 48 00
Fax: +32 (0)2 274 48 35
E-mail: contact@apd-gba.be
Website: www.dataprotectionauthority.be
Data storage
SWIFT hosts the Security Attestation application on its infrastructure located in Belgium.
SWIFT keeps back-ups of the Security Attestation application in its Dutch, Swiss, and
Belgian premises.
Limited retention and deletion periods
SWIFT will retain and delete personal data in the Security Attestation application in
accordance with the retention and deletion periods of the full attestation data as set out in
the Data Retention and Deletion section, and in any event for no longer than is necessary
for the purposes set out above. For more information, see section Data Retention and
Deletion
International Data Transfers
When granting access to their attestations, users are responsible to ensure they can
transfer their attestation data to their counterparties based on their bilateral agreements or
otherwise. SWIFT is only responsible to legalise the data transfers on its systems.
Sharing data
SWIFT will not share personal data submitted in the Security Attestation application with
any third parties, other than in accordance with this Policy.
28 August 2020 33
Specific User Responsibilities regarding Personal Data

Compliance
Users of the Security Attestation application (both as attesting users and counterparties) are
responsible for submitting and consulting the personal data in connection with the Security
Attestation application in compliance with this Policy and all applicable data protection laws
and regulations.
Data submitted on behalf of another individual
It is the responsibility of the attesting user to ensure that any personal data submitted in the
Security Attestation application was collected and is submitted in accordance with
applicable laws and regulations, including when one end user within their organisation or an
affiliated entity submits personal data relating to other individuals within their organisation or
group or relating to contact persons of an entity supervisor or a third party company
engaged to conduct an independent external assessment.
For example, the attesting user may have to ensure that such other individuals are informed
about the processing of their personal data in the Security Attestation application and about
this Policy.
Data accuracy
Users contributing personal data in their attestation must ensure that the personal data
submitted in the Security Attestation application is accurate and complete at the moment of
submitting such data, and remains up to date, among others by timely responding to
SWIFT’s requests to re-confirm, update, or delete the data.
Use restrictions of attestations of counterparties
Counterparties that receive access to the attestation of other users may only use such
personal data and other data in the attestation for the purposes and in compliance with the
protective measures set out in section User Roles and Responsibilities under
Confidentiality.
SWIFT Contractual Documentation
Without prejudice to the obligation for each user under the SWIFT General Terms and
Conditions to comply with all obligations and other mandatory instructions applicable to it as
set out in this Policy, the Customer Security Programme – Terms and Conditions govern the
access to and use of the Security Attestation application and, more generally, all matters
relating to SWIFT’s role and responsibilities in connection with the CSCF and this Policy.
For the latest available version of the SWIFT General Terms and Conditions and
Customer Security Programme – Terms and Conditions, see www.swift.com > About Us
> Legal > Terms & Conditions.
28 August 2020 34
SWIFT Customer Security Controls Policy Appendix A: Glossary of Terms
Appendix A: Glossary of Terms
Term Definition
Alliance Lite2 for Business Applications A SWIFT user or non-user organisation registered
(L2BA) application provider under the L2BA Programme that provides business
application offerings, in combination with shared
connectivity services, to SWIFT users.
Counterparty A user who has been granted access to the attestation
data of another user.
Cutover The point during the implementation process at which

SWIFT connects a customer to the FIN or a SWIFTNet
service (for example, FileAct or SWIFT WebAccess
(formerly, Browse)) for live traffic.
Data Baseline The list of information an end user needs to provide
during the security attestation submission process.
More information can be found in the Customer Security
Controls Attestation Baseline.
Data Consumption The workflow by which SWIFT users can share the
attestation data.
Data Contribution The workflow by which SWIFT users submit their
attestation data.
End user An individual within a user's organisation who accesses

Entity An 8-character BIC for which a user is required to
submit an attestation under this Policy.
General Data Protection Regulation The Regulation (EU) 2016/679 of the European
(GDPR) Parliament and of the Council of 27 April 2016 on the
protection of natural persons with regard to the
processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General
Data Protection Regulation (GDPR).
Group hub A SWIFT user or non-user organisation connecting
users within its corporate group and as further defined
in the Shared Infrastructure Terms and Conditions.
Jurisdictional overseer A supervisory authority that has responsibility to

oversee a market sector for an entire jurisdiction, for
example, market infrastructures, banking, national
financial stability, stability of a currency zone. The role
of jurisdictional overseer can be played by the Central
Bank or by a dedicated institution.
Messaging counterparty A user with whom a user has exchanged live FIN,
InterAct, or FileAct messages over the previous 403
calendar days, excluding RMA messages, MT 0xx, and
MT 999 messages.
Service Bureau A SWIFT user or non-user organisation registered
under the Shared Infrastructure Programme (SIP) that
provides services to connect SWIFT users that are not
affiliated with such an organisation.
28 August 2020 35
SWIFT Customer Security Controls Policy Appendix A: Glossary of Terms
Term Definition
Service provider An organisation that provides shared connectivity

services to users, including service bureaux, L2BA
application providers, group hubs and SWIFT hosted
connectivity offerings (that is, Alliance Lite, Alliance
Lite2, Alliance Cloud and Alliance Remote Gateway).
(SWIFT) Traffic aggregation hierarchy SWIFT users that part of the same corporate group
registered for the purposes of SWIFT traffic
aggregation. For more information about traffic
aggregation and applicable ownership criteria, see the
Pricing and Invoicing – Price List for SWIFT Messaging
and Solutions.
(SWIFT) user An organisation that SWIFT has admitted under the

Corporate Rules as a duly authorised user of SWIFT
services and products. The eligibility criteria to become
a SWIFT user are set out in the Corporate Rules.
28 August 2020 36
SWIFT Customer Security Controls Policy Appendix B: List of Acronyms
Appendix B: List of Acronyms
Acronym Meaning
BIC Business Identifier Code
CISO Chief Information Security Officer
CSCF Customer Security Controls Framework
CSP Customer Security Programme
GDPR General Data Protection Regulation
KYC Know Your Customer
L2BA Lite2 for Business Applications
PIC Partner Identifier Code
SIP Shared Infrastructure Programme
SOC Security Operations Centre
SUPE Supervised User
28 August 2020 37
SWIFT Customer Security Controls Policy Legal Notices
Legal Notices
Copyright
SWIFT © 2020. All rights reserved.
Restricted Distribution
Do not distribute this publication outside your organisation unless your subscription or order expressly grants you
that right, in which case ensure you comply with any other applicable conditions.
Disclaimer
The information in this publication may change from time to time. You must always refer to the latest available
version.
Translations
The English version of SWIFT documentation is the only official and binding version.
Trademarks
SWIFT is the trade name of S.W.I.F.T. SC. The following are registered trademarks of SWIFT: the SWIFT logo,
SWIFT, SWIFTNet, Sibos, 3SKey, Innotribe, the Standards Forum logo, MyStandards, and SWIFT Institute. Other
product, service, or company names in this publication are trade names, trademarks, or registered trademarks of
their respective owners.
28 August 2020 38

SWIFT Customer Security Controls Policy

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SWIFT Customer Security Controls Policy

Uploaded by

Copyright:

Available Formats

Customer Security Programme

SWIFT Customer Security Controls Policy

New information Location

Figure 1: Scope of the Customer Security Controls Framework

Key Policy Activities

Security Attestation Application

3 Security Attestation and Workflows

Figure 2: Data Contribution Workflow

Data submission workflow

Alliance Lite2 for Business Applications (L2BA) application providers:

- Users who alternate between service providers need to complete their

Data Publication and Validity

Sharing Attestations with Counterparties

The Download of Data

Administration and Configuration

User Management and Role Assignment

Approver • Reviews and approves attestations submitted by the Submitter

Data Retention and Deletion

Reporting to supervisors and other supervisory authorities such as jurisdictional overseers

Figure 1: CSCF Change Management Process, Security Attestation application,

6 Roles and Responsibilities, Data Protection,

SWIFT’s Roles and Responsibilities

User Roles and Responsibilities

User’s operational responsibilities

• in case of problems relating to or in connection with the Security Attestation

Purposes for which SWIFT will process Personal Data

• Maintaining and making the Security Attestation application available to users as

generally, (cyber-)security matters. Although this purpose relies primarily on

Specific SWIFT Responsibilities regarding Personal Data

Belgian Data Protection Authority

Specific User Responsibilities regarding Personal Data

Appendix A: Glossary of Terms

Cutover The point during the implementation process at which

End user An individual within a user's organisation who accesses

Jurisdictional overseer A supervisory authority that has responsibility to

Service provider An organisation that provides shared connectivity

(SWIFT) user An organisation that SWIFT has admitted under the

Appendix B: List of Acronyms

BIC Business Identifier Code

CISO Chief Information Security Officer

CSCF Customer Security Controls Framework

CSP Customer Security Programme

GDPR General Data Protection Regulation

KYC Know Your Customer

L2BA Lite2 for Business Applications

PIC Partner Identifier Code

SIP Shared Infrastructure Programme

SOC Security Operations Centre

SUPE Supervised User

You might also like