Independent Assessment Framework v2023 1.0

Confidentiality: Restricted Page: 1 of 38
Date: 30 June 2023

File name: Independent_Assessment_Framework_v2023
Link to this document: https://www2.swift.com/go/book/book200630
Customer Security Programme

Independent Assessment Framework
The purpose of this document is to provide Swift users and assessors with a comprehensive
overview of the independent assessment process and obligations.
Customer Security Programme Confidentiality: Restricted Page: 2 of 38
Date: 30 June 2023
Table of Contents
1 Preface 4
2 Assessment overview 6
2.1 Assessment Purpose 6
2.2 Assessment Process 6
2.3 Assessment Types 7
2.4 Assessor Independence 10
2.5 Assessor Qualifications 10
2.6 Assessment Costs Containment 12
3 Assessment Details 13
3.1 Assessment Scope and Timing 13
3.2 Point in Time Effectiveness and Evidence 13
3.3 Control Remediation 14
3.4 Reliance on the Previous Assessment’s Conclusions 14
3.5 Leveraging Common Control(s) Assessment Conclusion 17
3.6 Reliance on Another Report 17
4 Assessment and Risk-Based Approach 18
4.1 Assessment vs Audit Approach 18
4.2 Risk-Based Approach 19
5 Testing Methodologies 20
5.1 Potential Assessment Methods 20
5.2 Remote Assessments 21
5.3 Controls implemented in systems that are not in scope of the CSP 21
6 Assessment Resources 22
6.1 Security Guidance Documentation 22
6.2 Assessment Templates and Form 22
6.3 Training Material 23
7 Assessment Outputs and Attestation 24
7.1 Assessment Report and Completion Letter 24
7.2 Aligning the Attestation and the Assessment 25
7.3 Escalation to Supervisors and Counterparties 26
8 Special Cases 27
8.1 User Group Hub 27
8.2 Indirectly Connected Users 28
8.3 Other Third-Party Service Providers (Outsourcing Agent) 30

Date: 30 June 2023
8.4 Receiving-only profile 31
9 Delegation of the Submitter and Assessor Roles 32
10 Glossary of Acronyms 35
Annex A: Recommended Curriculum for Assessors 36
Legal Notices 38
Date: 30 June 2023
1 Preface
About this document
This document provides a framework for undertaking assessments against the Swift
Customer Security Controls Framework (CSCF). It is intended to support Swift users
and their assessors in carrying out their respective responsibilities.
Background
Swift created the Customer Security Programme (CSP) to promote cyber security in the
Swift user community and to drive industry-wide collaboration in the fight against cyber
threats. Users are responsible for the security of their infrastructure, and to support this,
the CSP has been designed to help combat end-point security threats and cyber fraud.
At the heart of the CSP programme is the Customer Security Controls Framework
(CSCF), a common set of security controls revised annually. The security controls help
users to secure their local environments and, in turn the Swift community overall.
Intended audience
This document is targeting the following audience:
• Swift users who need to perform an independent assessment to confirm their
level of compliance against the CSCF in force
• Internal/external assessors selected by the Swift users to assist them in the
Independent Assessment process
• Third-party organisations (called Outsourcing Agents) engaged by the Swift
user to whom they delegate the hosting, installation, operation, and/or
maintenance of components involved in their SWIFT connectivity, or providing
with a Swift-related application, and subject to the CSP program requiring to
provide comfort of controls applicable for outsourced components
Related documentation (Swift.com access required)

• Swift Customer Security Controls Framework (CSCF)
• Independent Assessment Process Guidelines
• High Level test plan and Evidence Guidelines
• Decision tree to determine the CSP Architecture type
• Outsourcing Agents Requirements
• Assessor Templates
• Customer Security Programme – Terms and Conditions
• Directory of CSP assessment providers
• Directory of Cyber Security Service Providers
• FAQ KB Article 5022902 on Independent Assessments
• FAQ KB Article 5021823 with specific clarification per control
• KYS-SA Security Attestation – User Guide
• KYC Security Attestation for Supervisors - User Guide
• Security Guidance documentation
• Swift Customer Security Controls Policy (CSCP)
• Swift General Terms and Conditions
• Swift Glossary
Date: 30 June 2023
Significant changes
The following table summarises the most significant changes (ordered by section
number) to the content of this document compared to the previous version. The table
does not include editorial changes that Swift makes to improve the usability and
comprehension of the document.
Section number Change

2.2 Assessment Process Illustration added to clarify process
Timeline
2.2 Assessment Process Activation of new BIC: clarify what is required

Timeline
2.5 Assessor Qualifications Clarification added on type of accepted type of
certification in cyber-security (pure audit
certification only is not sufficient)
3.4 Reliance on previous New clarified conditions to rely on previous
assessment’s conclusion assessment
3.6 Reliance on another Clarification on usage of other reports (example:

report ISAE) to support CSCF control(s) compliance
conclusion
4.1 Assessment vs Audit More precise comparison between the two review
approach approaches
5.3 Controls implemented in Control performed in systems not in scope of the

systems not in scope of the CSP is allowed
CSCF
6.2 Assessment Templates Clarification on the usage of Swift template as

and Form minimum set of information required
7.1 Assessment report and Clarification about minimum information expected

completion letter in the assessment report
8.2 Indirectly connected Special case – dedicated users in the interfaces of

Users the Service bureau/L2BA/Enablers
9. Delegation of Submitter Possibility to delegate the submission of the
and Assessor Roles attestation for approval by the independent
assessor
Whole document Clarifications in most of the chapters
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.
The CSCF Appendix D: “Glossary of Terms” also provides a definition of key terms
involved in the CSP.
Date: 30 June 2023
2 Assessment Overview
2.1 Assessment Purpose
To further enhance the integrity, consistency, and accuracy of attestations, and as
requested by the Swift Board and supported by the Swift’s Oversight, Swift mandates
that, at minimum, all mandatory controls of the attestation are independently
assessed.
It is required for independent assessor(s) to confirm that for CSCF the controls under
review, the control objective is met, the in-scope components are covered, and the risks
drivers are addressed. At a minimum, the mandatory controls must be independently
assessed. While the implementation of advisory controls is recommended but optional;
they must also be independently assessed when considered for inclusion in the
attestation.
The result of the assessment and related compliance level must be reflected in the
Know-Your-Customer Security Attestation (KYC-SA) application by the submission of an
annual attestation. Each attestation must be supported by assessment report(s) and
confirmation letter(s) (see “7.1 Assessment Report and Completion Letter” for more
info).
2.2 Assessment Process

The below illustration describes the typical CSP change management process. It
considers the annual release of the Customer Security Controls Framework update and
the influence on the attestation lifecycle:
CSP change management timeline

Date: 30 June 2023
The below illustration depicts a high-level summary of the different steps in the
assessment process, which are described in more details further in this document:
CSP Attestation process summary
2.3 Assessment Types

There are three types of assessment under the CSP. These are depicted below:
Types of assessment
2.3.1 Self-Assessment (Considered as Not Compliant)

The Self-Assessment ‘Assessment Type’ is performed by the first line of defence; these
are the functions that own and manage risks (without review by an independent
assessor).
Although still present in the KYC-SA application, a self-assessment, as per its name, is
not independent and hence is considered as ‘not compliant’ when submitting an
attestation in KYC-SA. As a result, the non-compliance status will be visible in real-time
by the counterparties of the users (after processed access request), and supervised 1
users will (a) appear on in real-time as “not compliant” in a dedicated application called
Know-Your-Customer for Supervisors (KYS), and (b) be reported in a bi-annual PDF
1
Users under the supervision of an institution’s supervisor. The supervision is the act of monitoring the financial performance
and operations of an institution to ensure that they are operating safely and soundly and following rules and regulations.
Institution’s supervision is conducted by governmental regulators and occurs to prevent institutions failures.
Date: 30 June 2023
reporting downloadable by their supervisors in the KYS application. It remains Swift

users’ responsibility and conscious decision to opt for a self-assessment.
Activation of a new BIC and assessment
Activation of a new BIC
As per the CSP Policy, a Swift user is obliged to have a published KYC-SA attestation to
activate a new BIC on the Swift network (that is, an attestation submitted against the
current active CSCF; all controls do not need to be compliant with).
To allow faster activation of a new BIC, a user can temporarily submit an attestation
supported by a self-assessment even if not yet fully compliant (the user might be unable
to conduct an independent (internal or external) assessment before BIC activation). This
selection should be done on a temporary basis only and an independent assessment
should be conducted as soon as practical.
Important note: as an exception, a BIC that has declared itself as receiving-only on

swift.com can have a compliant attestation with a Self-Assessment (even when its
attestation is not supported by an independent assessment). See section “8.4 Receiving-
only profile” for details.
2.3.2 Community-Standard Assessments

There are two flavours of independent assessment:
• Independent External assessment, performed by an independent external

organisation
• Independent Internal assessment, conducted by a user’s internal independent
department, such as second or third line-of-defence function; for examples
compliance, risk management or internal audit or its functional equivalent (as
appropriate). This function must be independent from the first line-of-defence
that approves the attestation (typically the CISO office or its functional
equivalent).
The lead assessors (whether internal or external) must possess recent and relevant
experience in the assessment of cyber-related security controls supported by adequate
qualifications (see chapter “2.5 Assessor Qualifications”).
For specific cases like a user Group-Hub, Service Bureaux (SB), Lite2 Business
Application Providers (L2BA), Outsourcing agents, please refer to Chapter 8: Special
Cases.
Date: 30 June 2023
Mixed assessment
Users can combine internal and external independent assessments; this corresponds to
a mixed assessment; for example, an independent assessor such as risk, compliance, or
internal audit validates some controls, whilst another external independent assessor
validates the others. A mixed assessment is acceptable if all applicable controls are
reviewed by at least one of the involved independent assessors.
2.3.3 Swift-Mandated External Assessments

As outlined in the Customer Security Controls Policy (CSCP), section “Quality
assurance”, Swift reserves the right to request a user’s BIC to provide assurance on the
accuracy of its KYC-SA attestation. This assurance requires an independent external
assessor to validate the requested user’s compliance with the applicable controls.
For the selected BICs, follow-up and execution of the mandatory external assessment is
essential to ensure strong security practices across the Swift ecosystem. Not
undertaking the mandatory external assessment represents a breach of the CSCP and
Swift reserves the right to report this breach to the relevant supervisor(s) and/or
counterparties of the selected BICs.
Selection
Every year, Swift aims to select a relevant cross-section of users to undertake mandated
external independent assessments. This process follows Swift’s main quality assurance
(QA) process 2.
The identified users’ BICs are randomly selected, however extra elements can be
applied in the selection including:
• User segments where analysis indicate they may be at high risk of an incident.
• Indication of an incident (re-)occurring for a specific user.
Process
When selected for the sample, Swift notifies the user via the CISO contact designated in
their last KYC-SA attestation. If the selected user believes that there are legitimate
reasons why a mandated assessment should not be undertaken, then this should be
promptly communicated to Swift by email to the [email protected] and
detailing the specific circumstances.
Swift requires selected users to appoint a third party (external) assessor and requests
the usage of standardised templates (or ensure same content is being used as
described in chapter “6.2 Assessment Templates and Form”) to undertake this external
assessment. Users have the free choice to select their external assessor, provided it
meets the assessor’s required criteria. The use of independent internal parties, including
the internal audit function, is not permitted for Swift-Mandated External Assessments.
Users can also make use of an assessor they are already engaged with for other internal
purposes. Users are required to inform Swift of the company they select for external
assessment services using a standardised notification template (provided by Swift).
2
The Customer Security Programme (CSP) Quality Assurance (QA) process is designed to provide both quantitative insight
and qualitative evidence of the operations around user attestations and counterparty data consultation.
Date: 30 June 2023
Users must finally notify Swift of the completion of the external assessment (by
contacting [email protected]) and submit or update their KYC-SA attestation
accordingly. Upon request, users must provide the Word-based completion letter
(translated in English as appropriate) to Swift.
Scope
Swift-Mandated External Assessments must cover at least all mandatory controls
applicable to the user’s architecture type as defined in the version of the CSCF that
must be met by the end of the year the assessment is conducted. In case the selected
BIC is connecting through a group hub, the mandated assessment is limited to the local
footprint of the BIC mentioned in the request, the group hub itself in this case is out-of-
scope. If the selected BIC is the group hub itself, then the Swift-Mandated External
Assessment is applicable to the group hub infrastructure.
Timeline
Swift aims to inform BICs selected for a Swift-Mandated External assessment in the first
quarter of the year for completion by 31 December of the same year. Unless specified
differently, the Swift-Mandated External Assessment must be conducted by the end of
the year of the initial request.
KYC-SA Alignment
If the outcome of the assessment highlights a different compliance status than the one
indicated in the user latest KYC-SA attestation, then in line with existing CSP policy, a
new attestation should be submitted within three months of the issuance of the Swift-
Mandated Assessment report.
2.4 Assessor Independence

To execute properly an assessment, the assessor must be free from any conflict of
interest and demonstrate a level of independence such that the activity is conducted in a
reliable and objective manner. Based on a definition from the Institute of Internal
Auditors (IIA), Swift characterises independence as follows:
Independence is the freedom from conditions that threaten the ability of the assessment
activity to carry out responsibilities in an unbiased manner… Threats to independence
must be managed at the individual assessor, engagement, functional, and organisational
levels
When an internal department (for example Internal Audit, Risk team, or Compliance
Department) is engaged to execute an independent assessment, users are advised to
take steps to ensure that those involved in the assessment execute their duties in an
objective way, free from undue influence (including but not limited to independent
reporting lines between assessors and controls owners).
2.5 Assessor Qualifications

When selecting an assessor (both internal or external), users must verify and ensure
that:
A. The external company or the internal department conducting the assessment

has recent (within two years) and relevant experience to execute a
Date: 30 June 2023
cybersecurity-oriented operational assessment toward an industry standard

such as PCI DSS 4.0, ISO 27002, NIST SP 800-53, SOC-2 (type 2), the NIST
Cybersecurity Framework or the CSP/CSCF. Other industry standards are
permissible if they provide the same level of robustness.
B. The lead assessor 3 (identified in the KYC-SA application as ‘assessor contact’)
must hold at least one industry-relevant professional cyber-security related
certification, and other individuals assigned to carrying out the assessment
should preferably hold similar certification.
Swift does not provide any comprehensive list of accepted certifications, nor
does it validate the adequacy of alternative certification. It is the responsibility of
the Swift user to confirm that the certification is linked to cyber-security related
field (an audit-oriented type certification without cyber-security coverage would
typically not be acceptable). However, few examples of commonly relevant
certifications are:
• PCI Qualified Security Assessor (QSA) - the PCI Security Standards Council
maintains a list of Qualified Security Assessors QSAs that can be found here
(for reference only)
• Certified Information Systems Security Professional (CISSP)
• Certified Information Systems Auditor (CISA)
• Certified Information Security Manager (CISM)
• ISO 27001 Lead Auditor
• System Administration, Networking, and Security Institute (SANS) GIAC
(Global Information Assurance Certification)
• Other professional certifications, from the local market and in local
language, are permissible if they provide the same level of robustness.
In all cases, Swift expects a close oversight, monitoring and accountability from the lead
assessor on the activities performed by the other individual members of the assessment
team.
Roles and Responsibilities
Swift does not endorse or accredit any specific assessor, users remain ultimately
responsible for selecting the assessor suitable to their needs and meeting the required
standards and certification fitting their purposes. Swift however publishes on the
swift.com website 4 a directory of CSP Assessment Providers (this is a list of companies
that offer services to assist in performing independent assessments). This list is not
limitative, Swift users are permitted to select an assessor who is not on this list. When
selecting an assessor (whatever from the directory or not), it is strongly recommended
that users challenge their Swift and CSP/CSCF knowledge and curriculum.
Companies listed on the assessment providers directory have been required to follow a
CSP curriculum to acquire or maintain their knowledge and understanding of Swift and
the CSP programme. Their presence in the directory reflects a successful completion of
the CSP curriculum by these assessors. Swift users that engage with a listed
3
Lead assessors are persons who are responsible for managing the assessment team in an organisation. They supervise the
preparation of the plan prepare the plan, usually deliver meetings and are the persons who provides the assessment
conclusions and report.
4
Organisations present in multiple countries will be displayed under a unique name not referring to a specific location
Date: 30 June 2023
assessment company are entitled to request the certificate of attendance of the

individual assessor they engaged with to demonstrate the acquired knowledge.
Note that external assessors may outsource some assessment activities to third parties
provided the latter fulfil the independence, expertise, skills, and credentials criteria as
outlined in this section, in full transparency to the user engaging with this external
assessor. The external assessor however remains fully accountable for activities
performed by the outsourced third party towards the user.
For Community-Standard and Swift-Mandated External Assessments, users must

confirm the name of the assessor company and the end date of the assessment (final
report date) in the KYC-SA application at the time they submit their attestation. It is
recommended to also provide the lead assessor’s contact details.
2.6 Assessment Costs Containment

Users are responsible for all costs associated with the independent assessments. To
contain these costs, users are advised to:
• Limit the review to an assessment; an audit is not required by the CSP

programme (see section “4.1 Assessment vs Audit Approach”)
• Identify the accurate architecture type (using the latest CSCF or the Decision
tree)
• Ensure an accurate scope for the assessment through proper identification of in-
scope components
• Apply sampling of components 5 wisely (Refer to the High Level Test Plan
Guidelines for guidance)
• Use internal vs external resources, or even mixed teams
• Leverage previous relevant assessment covering the control objectives and
elements in scope (see section “3.4 Reliance on the Previous Assessment’s
Conclusion”)
• Implement supervisory controls (that is, methods confirming the control
compliance in an automated and continuous way)
• Use Service Providers (for example SB/L2BA) to conduct the assessment (see
section “9. Delegation of the Submitter and Assessor Roles”)
• Leverage another third-party assurance or internal report (see section “3.6
Reliance on Another Report”)
5
At least one item of each in-scope components’ categories in each assessed environment (example: messaging interfaces,
communication interfaces, jump servers, general-purpose operator PCs, network components) must be assessed to confirm
their compliance with a control. However, if the population of a category is composed of a high quantity of items, sampling
can be used to obtain reasonable comfort as described in the High-Level Test Plan Guidelines document.
Date: 30 June 2023
3 Assessment Details
3.1 Assessment Scope and Timing
Scope
Independent assessments must at least cover all mandatory controls as set out in the
CSCF version of the applicable year, and in line with the Swift user architecture type and
infrastructure. It is however suggested to perform the assessment by using the latest
published CSCF version to benefit of the latest clarifications. Non-compliance to an
advisory control will not lead to a non-compliant attestation.
The assessment should at first confirm the adequate architecture type and encompass
all production, disaster recovery (DR), and/or backup environments (as applicable) that
host any of the in-scope systems, operators, and devices. This could lead to different
architecture types for each environment, each of them must be fully compliant (the most
encompassing architecture type must be specified in the attestation in KYC-SA).
The assessment must include all components of the user’s Swift-related infrastructure as
documented in the in-scope components section of each the control definition in the
CSCF.
Users must accurately define the assessment scope with their assessor during the
provider procurement process. This helps prevent later misunderstandings and mitigate
substantially against any risks associated with over or under-scoping the assessment
exercise.
Timing
Once the scope is established, a schedule of the assessment can be determined to

ensure that the report is delivered on time to enable the user to submit their associated
attestation in the KYC-SA application within the normal attestation window. This window
is from early July until the year-end deadline of 31 December. The schedule should
include the time needed for the assessor to document deviations to applicable controls,
to prepare the reports, to review any other deliverable at the assessment conclusion,
and to address potential identified deviations.
Users engaging with an external assessor should allocate appropriate time to prepare
for and contract with the appropriate external party to conduct the assessment. This
phase includes budgetary considerations (as appropriate) to support the selection and
procurement of an external assessor. Appropriate planning should take place within the
organisation to ensure assessors can undertake their work ahead of the KYC-SA
attestation deadline.
3.2 Point in Time Effectiveness and Evidence

Assessors need to confirm that the design of the assessed controls is adequate, and
their implementation is effective, at the time of the assessment. That means that the
assessment is defined as a point in time effectiveness review of the controls; as
corollary, there is no obligation for assessors to confirm the controls operational
effectiveness since the last user’s published KYC-SA attestation.
Date: 30 June 2023
Control implementation effectiveness must be supported by evidence, it remains the

assessor’s responsibility to determine the appropriateness of such evidence (for
guidance on typical evidence, refer to the document “High Level Test Plan and Evidence
Guidelines”).
There is no prescriptive approach to determine what is the adequate ageing of an

evidence, it typically depends on the control criticality and volatility. In any case, Swift
recommends using the most recent available evidence, as appropriate (but the evidence
must never be older than the previous CSP attestation cycle).
Users should securely retain evidence supporting the assessment conclusions for 5
years (with a minimum of 2 attestation’s cycles for potential further reliance). There is no
requirement to proactively provide any supporting evidence to Swift.
3.3 Control Remediation

Definition
Remediation is the activity of reviewing and adapting the design and/or the
implementation of a control to ensure its compliance with its objective and addressing
deviations raised by the assessor. This activity is typically performed when an
assessment has concluded that the design or the implementation does not sufficiently
cover the control objectives, its risk drivers, or the identified in-scope components (or a
combination of those).
Re-assessment
After remediation, a re-assessment of the deficient control(s) must be performed by an

independent assessor. The latter does not need to be the same assessor as the one that
identified the deviation. The scope of the validation following the remediation is
determined on a case-by-case basis and is supported by an agreement between users
and their independent assessor; the scope could potentially be limited only to the
portion of the affected control.
Submission of a revised attestation
Ideally, remediation should be validated before the submission of the attestation to avoid
any declaration of non-compliance. If the remediation and its validation are not
performed before the submission of the attestation in the KYC-SA application, then
control(s) with open deviation(s) must be marked with either the option (i) “I do not
comply” or (ii) “I will comply by <a given date>”, the latter with the best estimated
compliance date. In the latter case, a new attestation must also be submitted once the
deviations have been remediated and validated by an assessor.
If the target date for control compliance cannot be met, then a revised date must be
selected, and the control will still be considered as not compliant.
3.4 Reliance on the Previous Assessment’s

Conclusions
It is possible for a user to rely on control(s) conclusions from a previous independent
assessment cycle (irrespective of its type: internal, external, mixed, or Swift-Mandated)
to support the current year’s cycle assessment report. In any case, an annual attestation
must always be supported by an independent assessment, regardless of if this
Date: 30 June 2023
attestation is partially or fully based on reliance of previous compliance conclusion or

not.
To confirm if controls compliance conclusion from the previous assessment can be
relied on, the following two mandatory steps (illustrative below) must be performed:
Condition to rely on previous assessment cycle

Step 1. At report level
This step requires the user to confirm that the previous assessment and report
conclusions are permitted to be relied on: some contractual clauses agreed with the
assessor, internal policy, applicable regulations, or any other relevant reason could
prevent a previous assessment report to be leveraged.
This condition must be confirmed by the assessor, and potentially with the previous
assessor if different:
• If the previous assessment report can be relied on, then go to the step
2 to confirm for each control if its previous conclusion can be relied on.
• If the assessment report may not be relied on, then all controls must be
fully re-assessed and included in the new assessment scope (the step 2
below can be ignored).
Step 2. For each control for which previous assessment conclusion could be relied on,
confirm that all following re-usability conditions are satisfied:
(i) Assessment on the previous or the current CSCF version: The control
must have been effectively assessed against the same CSCF version, or the
previous CSCF version. For example, for an assessment conducted against
the CSCF v2023, the control compliance conclusion from the previous year
assessment must have been done against the CSCF v2023 or v2022, not
any other earlier CSCF version.
(ii) Control conclusion was not already relied on or based on another
assessment/assurance report: Conclusions of a control compliance
effectively tested a specific year can be relied on to support the following
year attestation cycle only. This means that a control compliance conclusion
can only support up to maximum two consecutive years attestation’s cycles:
the year of the assessment and the next year attestation cycle (ensuring that
a control is effectively assessed at least every two year’s attestation cycles).
For example, a control conclusion from an effective assessment in 2022
supporting the attestation cycle in 2022 can only be relied on to support the
attestation cycle in 2023, but not in 2024 or later.
Date: 30 June 2023
Furthermore, if the control conclusion of the previous assessment cycle was

based on another assurance report (examples: internal audit report,
ISAE3000) as described in “3.6 Reliance on Another Report”, the previous
cycle conclusion cannot be relied on. In this case, a full testing of the control
is required, or compliance conclusion can be relied on a newer version of
another report.
(iii) No impact by the new CSCF: The version of assessed CSCF does not
materially alter part of the control applicable to the user and its architecture
type since the previous assessment; that includes any relevant change on
the control objective, in-scope components, or risk drivers (or a combination
of those).
(iv) No control design or implementation change at user end: The control
design or implementation has not been altered by any significant change in
the user’s architecture, configuration, design, and implementation method
(or any combination of those). This condition must be analysed in terms of
impact; a change may indeed be assessed as limited and hence not directly
affecting the conclusion in the previous assessment.
• If all above four conditions are satisfied for a control, then the
compliance conclusion from the previous assessment for this control can
be relied on; however, it does not prevent the assessor from confirming
the continued correctness of the previous conclusion with, for example, a
limited testing of the control, as appropriate.
• If at least one of the above 4 conditions is not met, then this control
cannot be relied on and must be added to the current assessment scope.
The final scope of the new assessment is then composed of either:
• All controls, when the previous assessment or report may not be relied
on, as per step 1 above, or
• The sum of all controls which were not satisfying all the 4 reusability
conditions described above under step 2. Control(s) conclusions which
relied on a previous assessment must be marked as such in the
assessment report.
The below diagram illustrates, per control, the potential reliance options. The timeline is
for illustration purpose and can differ for every user.
Typical assessment cycle per control

Date: 30 June 2023
Important Note – assessment effort is always required for reliance

Reliance on conclusions from an earlier assessment report will always require
assessment effort (even if limited in comparison with a full scope assessment). Also, the
assessors must obtain comfort that same design and implementation of relied upon
controls is in place. That can be performed using various methods (examples: targeted
testing by the assessor, limited sample validation, demo, inquiries) confirming that the
control is still complied with. The assessor must always produce a new assessment
report reflecting for each control how the compliance conclusion was reached.
3.5 Leveraging Common Control(s) Assessment

Conclusion
When users have identical control(s) scope and implementation applying to multiple
BIC(s), the assessment conclusions can be leveraged by those BIC(s) and reflected as
such in the assessment report and in the attestation. For example, if for multiple BIC(s),
the same HR screening and staff vetting is applied, the physical controls of the secure
zone are identical, a shared logging and monitoring tool is used, or a same customer
connector is shared, then the assessment conclusion for those common control(s) can
be shared by all those BICs.
In case of shared interface(s) offered by a group hub, please refer to section “8.1 User
Group Hub” for more details on assessment specificities.
3.6 Reliance on Another Report

Reasonable comfort (as described in “4.1 Assessment vs Audit Approach”) on controls
compliance level can also be obtained through a third-party assurance report (For
example: an ISAE3000, ISO27002, SOC-2 – Type 2 or, PCI DSS 4.0) or an internal
report (produced by an internal independent department like internal audit, for instance).
Few conditions need to be validated to be allowed to rely on another report:
• The scope, components, and risks covered by the report must be accurately
reviewed to ensure that it is identical to the CSCF controls definition it will support. If
not, complementary assessment work might be required; and
• The period covered by the assessment/audit must not be older 18 months before the
attestation is submitted; and
• The company or department who issued the report must be qualified to perform the
related assessment/audit, and fully independent for the entity being assessed as per
section “2.4 Assessor Independence”
Date: 30 June 2023
4 Assessment and Risk-Based

Approach
4.1 Assessment vs Audit Approach
Swift has opted for an ‘assessment’ rather than an ‘audit’ review approach for the CSP.
Find below key differences between both approaches:
Topic Assessment Audit
Coverage An assessment provides point-in-time An audit provides reasonable assurance and

reasonable comfort about compliance of the formal compliance opinion on the operational
design and implementation effectiveness of effectiveness of controls for a defined period
controls agreed during the planning phase and depending
on the criticality of the entity being audited
(example 1 year)
Resources An assessment can be carried out by an Audit is performed by an independent internal

independent internal team, or be a third- audit department or external auditors, who have
party independent organisation, both with cyber-security skills, and led by a qualified and
confirmed cyber-security skills with the lead audit certified professional.
assessors holding a recognised cyber-
security certification (as described in chapter
2.5 “Assessor Qualifications”).
Sampling Sampling may be not necessary or limited in Recognised, qualified and documented sampling
comparison with an audit, a sample of one must be used to obtain assurance conclusion –
item could be sufficient to obtain comfort of Sample size depends on the period covered, the
the adequate implementation of a control. size of the population, and the level of confidence
required. (When possible, Data Analytics is used to
test full population)
Process An assessment follows the assessment An audit strictly follows recognised international
methodology described in this document methodology and audit standards, with defined
and described in the Independent standardised deliverables (example: IIA’s
Assessment Process Guidelines International Professional Practices Framework –
IPPF)
Duration An assessment typically takes limited For the same scope, an audit typically consumes
resources and time more resources and time than an assessment
Remediation An assessment provides a list of exceptions, An audit provides with a list of detailed exceptions
recommendation can be proposed but there and proposed recommendations, a formalised
is no obligation of formalised follow-up of the follow-up of the closure of the open observations
remediation by the assessors. must be performed by the auditors according to a
strict timeline.
Swift is agnostic whether comfort is provided by means of an assessment or an audit in

the context of the CSP, if the external company or internal independent department (as
well as the individual assessors) possess at least the necessary skills and certifications
as set out in Section “2.5 Assessor Qualification”.
Swift defines ‘Reasonable Comfort’ as:

‘A level of comfort that Management can obtain from internal or external independent
assessor when the:
• Appropriate level of independence, objectivity, knowledges, and skills of the

assessor(s) are ensured,
• Fair validation by the assessor(s) of control design and implementation,
confirming mitigation of risks as per the control objective,
Date: 30 June 2023
• Noted exception(s) do not materially impact the control’s ability to mitigate the
risk, or alternative controls compensate for the noted deviations.
External certifications (such as against Systems and Organisations Controls – SOC-2 or

any industry standard identified in Appendix E of the CSCF like NIST or PCI-DSS) that
cover CSCF controls, but also internal report produced by an independent internal
department (example: internal audit), can give Management such reasonable comfort
about the appropriateness of the controls as well as their operating effectiveness. The
scope of and approach used for control evaluation in the context of such external
assessments or certifications must be understood before relying, either in part or in full,
on them’. Details on the potential reliance on another report is described in chapter “3.6
Reliance on a third-party assurance report”.
4.2 Risk-Based Approach

Assessors must use a risk-based approach to assess the user’s compliance with the
CSP control definition; that is, assess the security goal, regardless of the implementation
method used. To comply with a CSP control, users must implement a solution that:
• Meets the stated control objective, and

• Covers the documented in-scope components relevant for the user’s
architecture and environments, and
• Addresses the stated risk drivers
The Control Statement of each control described in the CSCF is a suggested way to fulfil
the control objective and the Implementation Guidelines are common methods for
meeting the objective. Even if the guidelines can be a good way to start an assessment,
they should never be considered as an ‘audit checklist’ because each user’s
implementation can vary.
Therefore, if some implementation guidelines elements are not present or partially

covered, then mitigations as well as environment specificities must be considered to
properly assess the overall compliance and adherence level (again, as per the
suggested guidelines or as per alternatives implementation). Using suggested guidelines
or alternative methods are considered equivalent from a risk perspective.
Date: 30 June 2023
5 Testing Methodologies
Swift does not provide pre-packaged test methodology for use in the assessment
process. Assessors are solely responsible for determining the approach in designing test
cases and conducting assessment activities in line with industry best practices. For
general guidance, potential testing methodologies are outlined below.
5.1 Potential Assessment Methods

Swift recommends that assessors employ a mix of assessment methods appropriate to
the user’s individual circumstances. Overall, the degree of assessor emphasis on a
particular control should be proportional with the level of risk involved. Where alternative
implementation methods to the guidance defined by Swift have been employed by the
user, the assessor should obtain the same level of comfort regarding the risks and the
objective associated with the control in question (see Section 4.2 on Risk Approach).
Examples of assessment methods include, but is not limited to, the below approaches:
Inquiry
Conducting interviews with relevant personnel can provide insights into awareness of
controls and the organisation’s actual processes and procedures, which can contribute
to overall levels of comfort.
Observation
Comfort gathered through the direct observation of the existence of specific controls.
Inspection
Comfort gathered through the inspection of documents and records. Among the most
basic methods of assessing control implementation are a review of applicable user
documents such as policies, standards, processes, procedures, and run books. Review
of documentation is a relatively easy method of collecting assessment information
because it requires little impact on normal business operations. However, the degree of
comfort achievable by this method is limited, as it does not necessarily provide insight
into actual system settings, network configurations, personnel actions, nor other
potentially relevant practices.
However, the inspection of Swift-specific client documentation, such as operator guides

for installing and configuring Swift Hardware Security Modules (HSMs) can help to
establish a baseline level of comfort regarding the implementation of CSCF controls.
Re-performance
Hands-on system re-performance and sample evidence collection can provide further
levels of comfort. This method is best employed in the case of technical controls where
direct insight into system settings and configuration is beneficial. Evidence collected via
system testing often takes the form of screenshots and/or data extracts from applicable
systems and infrastructure components.
Date: 30 June 2023
5.2 Remote Assessments

There could be circumstances, such as a pandemic, preventing an on-site assessment.
By their nature, remote assessments introduce additional challenges to assertion of the
same level of comfort provided by an on-site assessment. Nevertheless, assessors can
still consider testing methods such as:
• For technical and organisational controls, assessors could rely on the review of
documentation: screenshots (for example, network diagrams), system extracts,
procedures complemented with remote staff interviews.
• For physical controls, assessors could combine a review of documentation (for
example, maps or schemas) with interviews and images or video recordings.
5.3 Controls implemented in systems that are not

in scope of the CSP
For some controls, comfort on control design and effectiveness may need to be
obtained from a system or a process which is not directly in the scope of the security
controls.
This is inherent to controls whose implementation relies on different teams or are

implemented in systems outside the CSP scope. If the objective of the control is met for
all in-scope components, wherever the actual implementation is performed, it must lead
to a compliant control implementation.
Find below typical examples:
• The control 2.9 “Transaction Business Controls” can be based on controls

performed outside the secure zone, like in the back-office of the Swift user
• The control 5.3A “Staff Screening Process” performed typically by the human
resources in their own systems
• The control 6.4 “Logging and Monitoring” where the logs are centralised and
monitored in a centralised system collecting data from multiple sources
Date: 30 June 2023
6 Assessment Resources
This chapter describes what resources proposed by Swift can be leveraged to prepare
the assessment and to support the review phase.
External assessors registered 6 with Swift have direct access to training and assessment
materials. The “annex A” lists resources available on swift.com and which can constitute
a curriculum for assessors engaged by users.
If a user opts for an external assessor that is not registered with Swift, then it is the
user’s responsibility to provide the assessor with the necessary assessment supporting
material in accordance with all applicable terms and conditions. As a minimum, these
resources are as follows:
• Customer Security Controls Framework (CSCF)

• Independent Assessment Framework (IAF - this document)
• Excel-based CSCF Assessment Templates and Word-based completion letter
(See Section 6.2 below)
• Completion letter and assessment report templates
• Security Guidance documentation (See Section 6.1 below)
• The CSP Policy (CSCP)
6.1 Security Guidance Documentation

Swift provides product specific Security Guidance documents. These set out Swift’s
security-related recommendations when using Swift products such as Alliance Web
Platform Server-Embedded, Alliance Access/Entry, Alliance Gateway, Alliance Lite2,
Microgateway, AGI, and Alliance Messaging Hub (AMH) SwiftNet Link. The mapping
between the CSP controls and the various Security Guidance recommendations is
provided in a separate document; for AMH, this mapping is included in the AMH
Security Guidance document itself.
Users of Swift products and their assessors are strongly encouraged to read and apply
the relevant security guidance documents and verify their implementation in their local
Swift set up.
Users of vendor (that is, non-Swift) product should reach out to their vendor for security
guidelines, otherwise, industry best security practices must be applied.
6.2 Assessment Templates and Form

For convenience and to ensure a consistent approach for the assessment process, Swift
provides users with standardised templates and forms. These include:
For Swift Mandated External Assessments only:
• An ‘Assessment Request Acknowledgement letter’, which a user must use to

acknowledge a request from Swift for a Swift-Mandated External Assessment
6
The assessors appearing in the directory of CSP assessment providers are registered under the Swift Partner Programme
Date: 30 June 2023
• A ‘Notification of External Assessor Selection’, which Swift user must use for
confirming its assessor selection to Swift
Swift will send those documents to users selected for a Swift Mandated Assessment.
For all Assessment Types (Mandated and Community Standard):
• Two Mandatory and Advisory controls assessment Excel-based templates

• An ‘Assessment Report’ and ’Assessment Completion letter’ Word-based
document
• A high-level test plan with potential supporting evidence and sampling
methodology
The assessment templates directly correlate to the CSCF and highlight which CSCF
controls are applicable to the user’s architecture type. For each applicable control, the
relevant template sets out the control objective and any underlying key principles. Using
the template, the assessor can then confirm whether controls applicable to the user are
met, either through Swift’s implementation guidance or by means of an alternative
implementation method.
Usage of Swift templates
The usage of the Swift templates’ documents is strongly recommended (examples:

assessment report template, assessors’ templates). To ensure harmonised methodology
and deliverables for the Swift users, if Swift templates as not used as such, topic
covered by those templates must be the minimum set of information part of the
deliverables provided by the assessors to the Swift users after the assessment.
The user can find the most up-to-date assessment materials online through the
swift.com portal. Swift recommends that users and assessors use the latest versions of
the forms and templates available to the Swift community.
Assessors can fill in the Excel assessment templates using their native language;
however, the Word-based completion letter must be completed in English or duly
translated, since Swift may request a copy.
No document must proactively be provided to Swift, they should be securely stored by

the assessor and the user to support the conclusions of the assessment.
6.3 Training Material

For users and assessors with direct access to the swift.com portal, up-to-date
SwiftSmart training resources are available on topics relating to CSP and CSCF. Swift
strongly recommends users to use the latest versions of these modules.
See also Annex A for additional training material and a comprehensive curriculum that
Swift recommends assessors with whom users engage to follow.
Date: 30 June 2023
7 Assessment Outputs and Attestation

7.1 Assessment Report and Completion Letter
The assessors are expected to provide users with the below documents at the
completion of their assessment:
• A formal assessment report containing at the minimum:

o The name, BIC and location of the Swift user assessed
o The assessment type (internal/external) and its purpose, along with the
CSCF version assessed
o (As applicable) the name and location of the external assessment
company
o The names and function of the assessors engaged
o The names and function of the key Swift user’s contacts involved in the
assessment
o The start and end date of the assessment, and the issuance date of the
final report
o The user architecture type(s), the environments covered (examples:
production, disaster/recovery), the scope, and the components
assessed
o A confirmation of the compliance level for each applicable control
(including how compliance conclusion was reached, examples: testing,
reliance on previous assessment (as per conditions described in section
3.4 “Reliance on the Previous Assessment Conclusion”), or on another
assurance report (See Section 2.5 “Reliance on Another Report” ),
along with documentation of observed implementation defects for non-
compliance subject to remediation.
• A completion letter confirming that the independent assessor was engaged by

the Swift user to assess its compliance level against the Customer Security
Controls Framework (specifying the CSCF version assessed). The completion
letter is the sole document that Swift could request to a user; however, there is
no need to proactively send it to Swift. The completion letter must be
appropriately signed by the lead assessor or the representative of the assessor’s
company or internal department. Handwritten signature or any alternative
acceptable formal signature applicable in the jurisdiction of the user (for
example chop in Asia).
In case multiple assessments performed by different assessors (example: in case of

mixed assessment), each of these assessors must produce a dedicated assessment
report and the related completion letter.
Every attestation and applicable controls (mandatory and advisory) compliance level
must be supported by one or multiple reports, and even if reliance on a previous
assessment is applied.
Documentation Storage
At the conclusion of assessment proceedings, users are advised to obtain all
assessment-related materials from their assessors (for example, evidence, working
papers).
Date: 30 June 2023
Users are expected to ensure the documents supporting the assessment are safely
maintained for the duration that the assessment supports their attestation (therefore for
minimum 2 attestation’s cycles, 5 years being recommended).
Users and assessors are encouraged to implement robust controls to limit access to
assessment materials in line with legal and regulatory requirements and applicable
confidentiality agreements.
7.2 Aligning the Attestation and the Assessment

Swift users must attest their compliance to the CSCF mandatory controls that are in
force at that time and that are applicable to them.
It is recommended that users will duly track resolution of non-compliance with their
assessors and, when addressed, submit a new attestation in the KYC-SA application
(see section “3.3 Control Remediation” for more information).
For all assessment types, users must take the following into account when planning the
timing of the assessment and the associated attestation in the KYC-SA application:
• The supporting independent assessment and report must comply with the
quality criteria outlined in this document.
• Users must complete a KYC-SA attestation consistent with the final assessment
report; that means that conclusions on the compliance of each individual control
must be accurately reflected in the KYC-SA attestation. It is typically the role of
the CISO or an equivalent senior level of IT management to approve the
attestation for review and publication by Swift.
o Note: The independent assessor (internal or external) or the service
bureau/L2BA serving the user (as appropriate) is allowed to draft of the
attestation and submit the filled attestation for approval to the CISO.
This possibility and conditions are further developed in “9 Delegation of
the Submitter and Assessor Roles”
• Users should submit their attestation in a timely manner, after the assessment
has been concluded (ideally within 30 days of the date of the assessment final
report). As corollary, attestations must not be submitted before the completion
of the assessment.
• The final report date supporting the attestation should ideally be, at the earliest,
within the year of the assessment exercise (for example, the submission of an
attestation against the CSCF v2023 must be supported by a report produced in
2023 at the earliest and validating at least the CSCF v2023 version or above).
• To reach compliance, users must attest within the attestation window from early
July to 31 December of that year. Users, and not their assessors, are always
responsible to approve the attestation.
Data relevant to the assessment and assessor (including the name and contact details
(optional) of the assessor, the assessment end dates, and the effort required to conduct
the assessment (in Man/Day – optional)) need to be provided in the KYC-SA application
when attestation is submitted.
Date: 30 June 2023
7.3 Escalation to Supervisors and Counterparties

The independent assessment is an integral part of users’ attestation obligations under
the Swift Customer Security Controls Policy.
Failure to undertake a Swift-Mandated or a Community-Standard Assessment, or in case

of the lack of compliance of at least one mandatory control, or if an assessment
becomes expired, will be visible as “not-compliant” to supervisors in real-time through
KYS, and also be reflected as such to counterparties granted access in the KYC-SA
portal.
Date: 30 June 2023
8 Special Cases
This section provides details on specific Swift connectivity set-up involving third parties
and are subject to specificities in terms of assessment and attestation.
8.1 User Group Hub

Definition
There are 2 types of user Group Hubs:
• A Swift user group hub offers a shared connectivity to its organisation through
a communication interface (and usually a messaging interface) that it owns.
• A non-Swift user Group Hub (previously called Internal Service Bureau) is a
non-Swift user organisation connecting affiliated Swift users within its corporate
group. A corporate group in this context means that:
o All connected users and the group hub belong to the same corporate
group based on the current criteria for Swift traffic aggregation and as
defined in the Price List for Swift Messaging and Solutions, or
o Connected users which include two or more Swift shareholders being
(together) majority shareholders of and exercising (together) effective
control over the group hub, and any other connected user belonging to
the same corporate group as that of any such shareholder based on the
then current criteria for Swift traffic aggregation (as defined in the Price
List for Swift Messaging and Solutions)
The CSP Policy states ‘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 Partner Identifier Code (PIC)
of the group hub. 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.’
User Group Hub and connected users' Attestation and independent assessment
In terms of KYC-SA attestation and independent assessment, the following rules apply to
user group Hubs: and their connected users:
• For the group hub:

o For a Swift user group hub, the BIC owning the shared communication
interface must assess and attest as architecture type A1
o For a non-Swift user group hub, the user heading the traffic
aggregation hierarchy or one of the connected shareholding users has
submitted a distinct attestation for the PIC, then the group hub PIC must
assess and attest as architecture type A1
• All connected users to the group hub (i) are architecture type A2, A3, A4 or B
as appropriate, (ii) refer in their attestation to the PIC/BIC as group Hub and (iii)
must assess and attest for their local footprint only.
If no connected user attests for the PIC of the non-Swift group hub, then no attestation is
provided for the group hub PIC and all connected users need to attest as A1 and
Date: 30 June 2023
perform an independent assessment covering both their local footprint and group Hub
PIC components. Stakeholders should agree to perform an independent assessment on
the PIC infrastructure, such independent assessment can be re-used by all stakeholders.
See below picture for more clarity:
Group hub implementation and related architecture type
8.2 Indirectly Connected Users

Indirectly Connected users are Swift users that engaged with a Service Provider under a
Swift Provider Security Programme like service bureaux (SB), Alliance Lite2 for Business
Applications (L2BA) Providers, Enablers like Business Connect (BC) Providers. Such
users must independently assess the controls applicable to their Swift infrastructure in-
scope components, knowing that the above-mentioned service providers are subject to
their own Swift programme.
For additional examples of architecture involving a service provider, please refer to the
Swift Customer Security Controls Framework or to the decision tree examples section
(see 1.2 “Related Documents”).
The figure below shows the scope of the CSP for the Swift user using a service provider
offering connectivity:
Date: 30 June 2023
Scope of CSP versus Service Provider under Swift provider programmes
Special case – dedicated users defined in the shared interfaces or product

provided by the providers
Dedicated users (examples: business operators, security officers, users’ administrators)

configured for the Swift user in the shared Messaging Interface (or similar product) of
the service provider are not in the scope of the Swift audit applicable to these service
providers, but in the CSP scope of the user.
Therefore, those dedicated users and related privileges must be reviewed as part of the
CSP assessment of the Swift user (mainly to ensure adequate segregation of duties), as
depicted in the below diagram:
Dedicated users in scope of CSP in service provider components

Date: 30 June 2023
Attestation of users serviced by a Service Bureau with a regular BIC code but not a
PIC code
There are service providers that are also Swift user with their own BIC. They are also
subject to the CSP for such BIC. They have a Swift infrastructure (typically a messaging
and communication interface), which is, at the same time, shared with other non-owner
third party BICs. In terms of KYC-SA attestation and independent assessment:
• The owner BIC attests as A1 in KYC-SA. For the purpose of its independent
assessment, this owner BIC can rely on the service provider inspection results
(provided those satisfy the reliance conditions described in this document) for
the overlapping part of the CSP controls. It will however need to complement
the service provider coverage with an assessment covering the non-overlapping
part such as general-purpose operator PC or end-users. The owner BIC must
refer in its attestation to both the service provider inspection and to the
assessment of this non-overlapping independent assessment. Note for
inspection: the inspection report is available to the service bureau/L2BA
provider as it is delivered at completion of the inspection; there is no need for
any formal approval from the SIP auditors to rely on the final SIP report; details
regarding components typically reviewed as part of the SIP Programme are
available in the KB article 5024785
• The non-owner BICs (i) attest as A2, A3, A4 or B as appropriate, (ii) refer to the
owner BIC as service bureau and (iii) conduct an independent assessment
covering their local footprint only.
Reliance on controls compliance conclusions from a service provider audit

inspection
Under specific conditions, users can leverage the conclusions from an audit inspection
of their service provider to confirm their compliance to CSCF controls applicable to
them. When the conditions described below are met, only the recent audit report (from
the year or the year before) can be relied on. The Service Bureau or L2BA Self-
Assessment can never be leveraged (only an audit).
To leverage a service provider audit inspection, following conditions apply:
• This audit must have been performed on the controls that are part of the current
or the previous PSCF version of the year the CSP attestation applies. For
example, to support control(s) compliance conclusion for an assessment against
the CSCF v2023, the control compliance conclusion from the service provider
audit inspection must have been performed on either the PSCF v2023 or v2022,
but not any other earlier PSCF version.
• The user must confirm that those CSP controls covered by the service provider
inspection are adequately covered and assessed compliant as described in this
document (meaning that the control objective is met, all in-scope components
covered, mitigating the related risks).
8.3 Other Third-Party Service Providers

(Outsourcing Agent)
Users engaged with another third parties not falling under the scope of a Provider
Security Programme as described above (for example, an IT provider or a Cloud
provider, but not a Service Bureau or L2BA) to host or operate (in full or in part) their
Date: 30 June 2023
own Swift infrastructure must obtain reasonable comfort from such third parties
(referred to as outsourcing agents) that the outsourced activities or externally hosted
components are protected in line with the relevant CSCF security controls.
Outsourcing agent high-level model
Users are still responsible and accountable for the assessment of all their in-scope
components for the comprehensive implementation (as if it was not outsourced).
Detailed information regarding the outsourcing agents expectations, <roles and

responsibilities, assessment approaches, and guidelines to perform and submit the
attestation is described in a dedicated document: “Outsourcing Agents Requirements ”.
8.4 Receiving-only profile

Some Swift Users may decide that some or all their BIC(s) only receive FIN and Swiftnet
(InterAct and/or FileAct) messages (those are BICs used for instance to only receive
bank statements). Such users have the option to declare those BICs as ‘Receiving-only’
through a swift.com e-form, thereby confirming their commitment not to send messages.
The KYC-SA attestations for those BIC(s) will subsequently expressly reflect their status
as Receiving-only and their KYC-SA counterparties will be notified about their new
‘Receiving-only’ profile.
Users that declared themselves as Receiving-only will be considered as compliant with

the CSP even if their attestation is not supported by an independent assessment. A
yearly attestation is however still required.
Users can terminate their ‘Receiving-only’ profile by submitting the relevant e-form on
swift.com. The termination request is subject to the user having a published KYC-SA
attestation. At the same time, their KYC-SA attestation must again be supported by an
independent assessment. Furthermore, they will no longer be flagged as Receiving-only
users in the KYC-SA application and their counterparties will be notified of the change.
Conditions for Receiving-only users are detailed in the KB Article 5025506.

Date: 30 June 2023
9 Delegation of the Submitter and

Assessor Roles
Independent assessor can, under some conditions, be involved in the attestation
process as submitter of the draft of the attestation. The final approval of the attestation
before publication by Swift remains however with the CISO (or equivalent IT
management position) of the swift user.
Service Providers (such as service bureau, L2BA providers) may also support their
users in (i) the attestation submission process or (ii) act as an independent assessor.
Those Service Providers have indeed a close relationship with their users and their
involvement in the attestation and independent assessment processes, can help improve
the overall accuracy and timeliness of their users’ attestation.
A. KYC-SA Submitter Role for a Service Provider or the assessor

From a contractual and legal perspective, Service Providers or assessors who want to
be appointed as KYC-SA Submitter 7 for their users are expected to ensure that (without
limitation):
• The delegation of this role to the Service Provider or the independent assessor
is duly documented and formally agreed between both parties, and
• The delegation covers at a minimum: timings, protocol for exchanging
attestation information, confidentiality, respective parties’ roles, responsibilities,
and liabilities
The delegating user must set up and apply the 4-eyes principle in KYC-SA. This set-up
is designed to always hold the accountability for the attestation with the delegating Swift
user.
B. Service Provider as an Independent Assessor

Service Providers intending to be appointed as assessor for their users must meet the
following conditions (without limitation):
• Teams and individuals conducting assessments must meet minimum standards

related to skills and credentials. See details of those minimum standards in the
section 2.5 above, and
• The Service Provider individuals appointed as assessors must be free from any
conflict of interest and demonstrate a level of independence to ensure that the
assessment is conducted in a reliable and objective manner. For example, the
Service Provider should not perform any assessment of its own
activities/services, even when conducted through independent individuals. This
condition refers to the independence clause articulated in the Section 2.4
above. And,
• Service Providers subject to the SIP or L2BA/BC programmes must be
compliant with such programme at the start time of the assessment (that is,
published on swift.com)
7
A Submitter can create, edit and submit the attestation for approval to the Approver who is releasing the attestation to Swift
for publication
Date: 30 June 2023
Delegating users must ensure that the selection and engagement of their assessor
complies with all applicable laws and regulations and, without forming any adverse
opinion regarding the general application of previously mentioned text, does not give
rise to any violation of competition law. For example, by using as independent assessor
a competitor of the appointed third-party Service Provider (service bureau, L2BA or
other).
Practicalities
Access to the KYC-SA Application to Assist in the Attestation Process
• The Service Provider must (i) be a registered Service Provider with a Partner
Identifier Code (PIC) or “soldto”, (ii) have a swift.com account and, (iii) have a
swift.com profile for each BIC for which it wants to be delegated a KYC-SA
Submitter role.
o For an external independent assessor, a dedicated swift.com user
account must be created under the sold-to of the Swift user
• The swift.com email address can be the same, but the Service Provider must
create a different user profile for each BIC. Useful links:
o Registration User Guide
o Identity Management: Request another profile
• The user’s swift.com administrator must approve the request from the Service
Provider or the independent assessor for the creation of a swift.com account
(profile) linked to the user’s BIC
• The user’s KYC-SA administrator must give the KYC-SA Submitter role to the
Service Provider’s or independent assessor swift.com account
• When logging in to the KYC-SA application, the Service Provider or independent
assessor must select the correct swift.com profile (for example, if a Service
Provider or the independent assessor has 10 users for different Swift users, it
will have at least 10 different swift.com profiles to select from when logging in)
As an example:
o The Service Provider creates an e-mail account for its staff in charge of
submission, such as kyc_submitter@service_provider.com
o On swift.com, the individual creates a swift.com account and links
kyc_submitter@service_provider.com with each BIC for which they will
submit an attestation
o In KYC-SA, the KYC-SA administrator of each BIC assigns the KYC-SA
submitter role to the related swift.com profile
(kyc_submitter@service_provider.com) of the Service Provider
o When connecting to swift.com, the account
kyc_submitter@service_provider.com selects the entity (BIC) for which
the attestation is submitted
Service Provider Publication as Independent Assessor on Swift.com directory
• A Service Provider can apply to become a listed CSP assessor by following the
Partner Programme process
• Swift will consequently conduct certain due diligence activities before publishing
(with potential refusal) the Service Provider in the directory of CSP assessment
providers on swift.com (subject to the formal registration and fees as per the
Partner programme and Cyber Security Service Provider terms of use)
Date: 30 June 2023
• The publication of an organisation as a CSP assessor requires passing of

SwiftSmart curriculums
Date: 30 June 2023
10 Glossary of Acronyms
Term / Acronym Definition
AICPA American Institute of Certified Public Accountants
BC Business Connect
BIC Business Identifier Code
CA Chartered Accountant
CISA Certified Information Systems Auditor
CISM Certified Information Security Manager
CISSP Certified Information Systems Security Professional
CPA Certified Public Accountant
CSCF Customer Security Controls Framework
CSCP Customer Security Controls Policy
CSP Customer Security Programme
GIAC Global Information Assurance Certification
HSM Hardware Security Module
IIA Institute of Internal Auditors
IPPF International Professional Practices Framework
ISO International Organization for Standardization
ISP Internet Service Provider
KYC-SA Know Your Customer – Security Attestation
KYS Know Your Customer for Supervisor
L2BA Lite2 Business Application
PCI DSS Payment Card Industry Data Security Standard
PIC Partner Identifier Code
QSA Qualified Security Assessor
SB Service Bureau
SIP Shared Infrastructure Provider
SOC System and Organisation Controls
SNL SwiftNet Link
Date: 30 June 2023
Annex A: Recommended Curriculum for

Assessors
To conduct an effective assessment of a CSP user footprint, Swift strongly recommends
assessors engaged by users to be familiar with the CSP Programme using relevant Swift
resources. See below a recommended list of documents to read to be prepared for the
assessment related activities.
Documentation
• Swift Customer Security Controls Framework – (translated versions available)

• Swift Customer Security Controls Policy
• FAQ Article (5022902) on Independent Assessments
• FAQ Article 5021823 on Controls clarifications
• FAQ Article 5025129 on CSP generic information
• Independent Assessment Framework and Templates – (translated versions
available)
• Decision Tree
• Swift products Security Guidance
• High-Level Test Plan Guidelines
SwiftSmart modules
• CSP/Customer Security Controls Framework modules

• Swift Products specific as appropriate (Alliance Access, Alliance Gateway, AMH,
HSM, Alliance Web Platform)
• SwiftSmart module related to the Independent Assessment Framework (IAF)
CSP Trainings
• Swift Assessment Guidelines Workshop

• Security Boot camp
• The Cyber Security Game
Note: translated versions are sometimes available; those are provided on a best effort
basis and out of courtesy; only the English version is the official version.
The below diagram is a guidance in which order the different key documents should be
read (however, it is not an exhaustive list):
Date: 30 June 2023
Date: 30 June 2023
Legal Notices
Copyright
Swift © 2023. All rights reserved.
Restricted Distribution
This publication contains Swift or third party confidential information. Do not disclose this
publication outside your organisation without Swift’s prior written consent. You may however share
this publication on a need-to-know basis with third parties that support you in connection with the
Swift Customer Security Programme initiatives provided (i) you inform the recipient of the
confidential nature of the information and (ii) you ensure that it is bound by no less stringent
obligations of confidentiality.
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: 3SKey,
Innotribe, MyStandards, Sibos, Swift, SwiftNet, Swift Institute, the Standards Forum logo, the Swift
logo, Swift gpi with logo, the Swift gpi logo, and UETR. Other product, service, or company names
in this publication are trade names, trademarks, or registered trademarks of their respective
owners.

Independent Assessment Framework v2023 1.0

Uploaded by

Copyright:

Available Formats

Independent Assessment Framework v2023 1.0

Uploaded by

Document Information

Original Description:

Original Title

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

Independent Assessment Framework v2023 1.0

Uploaded by

Copyright:

Available Formats

Confidentiality: Restricted Page: 1 of 38

Date: 30 June 2023

Customer Security Programme

2.1 Assessment Purpose 6

2.2 Assessment Process 6

2.3 Assessment Types 7

2.4 Assessor Independence 10

2.5 Assessor Qualifications 10

2.6 Assessment Costs Containment 12

3.1 Assessment Scope and Timing 13

3.2 Point in Time Effectiveness and Evidence 13

3.3 Control Remediation 14

3.4 Reliance on the Previous Assessment’s Conclusions 14

3.5 Leveraging Common Control(s) Assessment Conclusion 17

3.6 Reliance on Another Report 17

4 Assessment and Risk-Based Approach 18

4.1 Assessment vs Audit Approach 18

4.2 Risk-Based Approach 19

5.1 Potential Assessment Methods 20

5.2 Remote Assessments 21

6.1 Security Guidance Documentation 22

6.2 Assessment Templates and Form 22

6.3 Training Material 23

7 Assessment Outputs and Attestation 24

7.1 Assessment Report and Completion Letter 24

7.2 Aligning the Attestation and the Assessment 25

7.3 Escalation to Supervisors and Counterparties 26

8.1 User Group Hub 27

8.2 Indirectly Connected Users 28

8.3 Other Third-Party Service Providers (Outsourcing Agent) 30

8.4 Receiving-only profile 31

9 Delegation of the Submitter and Assessor Roles 32

Annex A: Recommended Curriculum for Assessors 36

Related documentation (Swift.com access required)

Section number Change

2.2 Assessment Process Activation of new BIC: clarify what is required

3.6 Reliance on another Clarification on usage of other reports (example:

5.3 Controls implemented in Control performed in systems not in scope of the

6.2 Assessment Templates Clarification on the usage of Swift template as

7.1 Assessment report and Clarification about minimum information expected

8.2 Indirectly connected Special case – dedicated users in the interfaces of

2.2 Assessment Process

CSP change management timeline

CSP Attestation process summary

2.3 Assessment Types

2.3.1 Self-Assessment (Considered as Not Compliant)

reporting downloadable by their supervisors in the KYS application. It remains Swift

Activation of a new BIC and assessment

Activation of a new BIC

Important note: as an exception, a BIC that has declared itself as receiving-only on

2.3.2 Community-Standard Assessments

• Independent External assessment, performed by an independent external

2.3.3 Swift-Mandated External Assessments

2.4 Assessor Independence

2.5 Assessor Qualifications

A. The external company or the internal department conducting the assessment

cybersecurity-oriented operational assessment toward an industry standard

Roles and Responsibilities