Control Definition
Control Objective: Ensure the protection of the local SWIFT infrastructure from risks exposed by the outsourcing of critical activities.
In-scope components:
- Organisational control is applicable when outsourcing critical SWIFT-related activities to a third party or a service provider.
Note: This control remains strongly recommended even when the activities being outsourced are not critical.
Risk Drivers:
- exposure to sub-standard security practices
Implementation Guidance
Control Statement:
Critical outsourced activities are protected, at a minimum, to the same standard of care as if operated within the originating organisation.
Control Context:
When critical activities are outsourced to third parties (for example, external IT provider or cloud provider) or service providers (such as a service bureau or a Lite2 for Business Application provider), it is essential that at a minimum, the original standard of care for security is maintained (in addition to adherence to this security control framework) to make sure that no new weaknesses or vulnerabilities are introduced.
Note:
- SWIFT defines the following activities, at a minimum, as critical:
- security management and change management of the hardware and software (including applications, operating system, and underlying virtualised platform or infrastructure) supporting the SWIFT service
- RMA-related operations
- accessing sensitive user data (for example, message content)
- monitoring of events that contain sensitive user data
- network management and configuration
- SWIFT-related transaction operations (for example, creation or modification of a financial transaction message within the messaging interface)
Implementation Guidelines:
The implementation guidelines are common methods to apply the relevant control. The guidelines are a helpful way to begin an assessment, but should never be considered as an "audit checklist" as each user’s implementation may vary. Therefore, in cases where some implementation guidelines elements are not present or partially covered, mitigations as well as particular environment specificities must be considered to properly assess the overall compliance adherence level (as per the suggested guidelines
or as per the alternatives).
- When outsourcing the SWIFT infrastructure (or a part of it) to a third party (such as an external IT provider or a cloud provider such as the Digital Connectivity Initiative) acting on its behalf, the user remains responsible for the conformance with the security controls of this framework and must seek compliance from that third party.
- When the third party provides shared services to connect no-related SWIFT users, the third party must be registered for the Shared Infrastructure Programme (SIP) or the Alliance Lite2 for Business Applications (L2BA) programme. Users remain responsible for their own infrastructure, organisation, and for implementing secure data flows toward the provider in line with the provider’s specifications. Users are also responsible for monitoring the provider’s compliance with the relevant SIP or L2BA programme33:
- Service bureaux registered and compliant under the SIP are listed in the SWIFT Partner Programme Service Bureau Directory.
- L2BA providers registered and compliant under the related programme are listed in the Lite2 Business Applications Providers Directory.
- Service Level Agreements (SLAs) and a Non-disclosure Agreement (NDA) are established with any third party or service provider when critical activities have been outsourced. These SLAs define the standard of care under which those critical operations are carried out by the third party or the service provider.
- A risk assessment of the third party is conducted at the start of the engagement, and is reviewed on aregular basis thereafter.
Note: SWIFT expects this control to become mandatory in a future version of this document.
