C H A P T E R 0 4
The 25 Mandatory Controls — Detailed Breakdown
The CSCF v2025 defines 25 mandatory controls distributed across the three security objectives. Each control specifies what the institution must implement, and during an independent assessment, the assessor will verify compliance through a combination of documentation review, staff interviews, configuration inspection, and technical testing. Below is a practical breakdown of the controls grouped by objective, including the type of evidence typically required.
Objective 1: Secure Your Environment (14 mandatory controls)
The majority of mandatory controls fall under this first objective, reflecting SWIFT's emphasis on building a secure and isolated environment for messaging operations. Key control areas include restricting internet access from the SWIFT secure zone, which requires institutions to demonstrate that no direct internet browsing or general-purpose email is possible from systems within the SWIFT infrastructure boundary. The SWIFT footprint restriction control requires a documented and verified inventory of all SWIFT-related hardware, software, and network components, ensuring the institution knows exactly what constitutes its SWIFT environment.
Virtualisation security controls require that any virtualised SWIFT components are hardened to the same standard as physical infrastructure, with appropriate hypervisor security configurations. Operator PC security mandates that workstations used to access SWIFT applications are locked down, segregated from general corporate networks, and protected against malware. Data exchange protection controls address how SWIFT-related data is handled when it moves between systems — requiring encryption in transit and secure file transfer mechanisms.
Objective 2: Know and Limit Access (6 mandatory controls)
The access-related controls focus on ensuring that only authorised personnel can interact with SWIFT systems, and that their access is appropriately scoped. Physical security controls require restricted access to rooms and facilities housing SWIFT infrastructure, with access logging and regular review. Staff screening and security awareness training must be documented and recurring — a one-time onboarding session is insufficient. Identity management requires unique user accounts with multi-factor authentication for all interactive sessions. This is one of the most frequently failed controls during assessment, as many institutions still rely on shared accounts or single-factor authentication for certain SWIFT-related applications. Privileged access management requires that administrative accounts are tightly controlled, with access granted on a least-privilege basis and subject to regular review.
Objective 3: Detect and Respond (5 mandatory controls)
The detection and response controls require institutions to demonstrate that they can identify and act on security threats within the SWIFT environment. Vulnerability scanning must cover all SWIFT-related systems and be performed at defined intervals, with evidence of remediation for identified vulnerabilities. Penetration testing must specifically target the SWIFT environment — a general corporate penetration test that excludes SWIFT infrastructure does not satisfy this control. Logging and monitoring requirements mandate that security-relevant events are captured, stored, and reviewed. The incident response plan must include SWIFT-specific scenarios, not just generic incident response procedures. Change management controls require that modifications to SWIFT infrastructure follow a documented and approved change process.
| Objective | Control Area | What It Requires | Common Evidence |
|---|
| Secure Your Environment | Internet access restriction | No direct internet from SWIFT secure zone | Firewall rules, proxy logs, network diagrams |
| Secure Your Environment | SWIFT footprint restriction | Documented inventory of all SWIFT components | Asset register, network topology, component list |
| Know and Limit Access | Identity management / MFA | Unique accounts, MFA for all interactive sessions | AD/LDAP config, MFA solution screenshots, access review logs |
| Detect and Respond | Penetration testing | SWIFT-specific pen test covering secure zone | Pen test report with SWIFT scope, remediation tracker |
| Detect and Respond | Incident response | SWIFT-specific IR plan, tested within 12 months | IR plan document, tabletop exercise records, escalation matrix |
For a full walkthrough of how EIC assesses each of these controls during an independent SWIFT CSP assessment, visit our service page or schedule a scoping call with our team.
C H A P T E R 0 5
Assessment Types — Independent vs Self-Assessment
Prior to 2021, SWIFT permitted institutions to self-attest their compliance with the CSCF. The institution's CISO or IT security officer could complete the KYC-SA attestation based on an internal review, without any independent verification. That model changed significantly in 2021, when SWIFT introduced the requirement for independent external assessment for most architecture types. Since then, institutions operating under architecture types A1, A2, and A3 must engage an external assessor to validate their compliance before submitting their annual attestation.
The rationale for this change was straightforward: self-attestation had led to inconsistent compliance levels across the SWIFT community. Some institutions attested full compliance while having material control gaps. Independent assessment provides assurance that the attestation accurately reflects the institution's security posture. The shift mirrors a similar evolution in PCI DSS, where self-assessment questionnaires coexist with on-site assessments conducted by Qualified Security Assessors (QSAs).
Who Qualifies as an Independent Assessor?
SWIFT maintains a directory of firms authorised to conduct CSP assessments. These firms must demonstrate competence in information security, relevant certifications (such as CREST, ISO 27001 Lead Auditor, or CISA), and experience with SWIFT environments. The assessor must be independent of the institution being assessed — internal audit teams cannot fulfil this role. SWIFT does not prescribe a specific certification for assessors in the way that PCI SSC requires QSA certification, but the expectation is that the assessing firm has demonstrable expertise in SWIFT infrastructure security.
What the Assessment Covers
An independent SWIFT CSP assessment covers all mandatory controls applicable to the institution's architecture type. The assessor will review documentation (policies, procedures, network diagrams, asset inventories), conduct interviews with key personnel (SWIFT administrators, security team members, IT operations staff), and perform technical testing to verify that controls are implemented as described. This may include reviewing firewall configurations, verifying MFA enforcement, inspecting logging configurations, and examining vulnerability scan and penetration test results.
Documentation for KYC-SA
Upon completion of the assessment, the assessor produces an assessment report that is uploaded to the KYC-SA application alongside the institution's attestation. The report typically includes a control-by-control assessment, evidence references, any identified gaps, and a signed assessor letter confirming the assessment was conducted in accordance with SWIFT's guidelines. Institutions should plan for the assessment report to take two to three weeks to finalise after fieldwork concludes.
Typical Assessment Timeline
A well-planned SWIFT CSP assessment typically spans 10 to 12 weeks from engagement to final report delivery. The timeline breaks down as follows: weeks 1-2 for scoping and document request, weeks 3-4 for documentation review, weeks 5-7 for on-site or remote assessment fieldwork, weeks 8-9 for gap remediation (if required), and weeks 10-12 for final report production and KYC-SA submission support. Institutions should begin the process no later than September to ensure the attestation is submitted comfortably before the 31 December deadline.
EIC's track record: EIC has completed 15+ SWIFT CSP assessments across seven Asia-Pacific countries, covering all architecture types. Our team includes certified assessors with hands-on experience across Alliance Access, Alliance Lite2, and service bureau environments.
C H A P T E R 0 6
Common Gaps and How to Address Them
Based on EIC's experience conducting SWIFT CSP assessments across the Asia-Pacific region, certain control gaps recur with notable frequency. These are not obscure edge cases — they represent systemic challenges that many institutions face when preparing for their annual assessment. Understanding these common gaps in advance allows your institution to address them proactively, avoiding the remediation delays that can jeopardise your attestation timeline.
1. Incomplete SWIFT Infrastructure Inventory
The SWIFT footprint restriction control requires a complete and accurate inventory of all components within the SWIFT secure zone — servers, workstations, network devices, software, and interfaces. In practice, many institutions have an incomplete asset register that omits peripheral systems such as jump servers, file transfer gateways, or monitoring agents that interact with the SWIFT environment. An assessor will compare the documented inventory against the actual environment and flag any undocumented components.
Remediation: Conduct a thorough discovery exercise that includes network scanning, physical inspection, and interviews with SWIFT administrators. Document every component that sits within or connects to the SWIFT secure zone, including supporting infrastructure such as DNS servers, NTP servers, and backup systems that service SWIFT components.
2. Network Segmentation Failures
SWIFT requires that the secure zone — where SWIFT messaging and communication interfaces reside — is logically or physically segmented from the general corporate network. The most common segmentation failures include overly permissive firewall rules that allow unnecessary traffic between the corporate network and the SWIFT secure zone, flat network architectures without proper VLAN segmentation, and missing or misconfigured access control lists on network devices.
Remediation: Review and tighten firewall rules to enforce least-privilege network access. Implement dedicated VLANs for the SWIFT secure zone with explicit deny-all default policies. Document the network segmentation architecture and test it periodically to confirm that only authorised traffic flows between zones.
3. Weak Operator Session Security (MFA)
Multi-factor authentication is required for all interactive sessions with SWIFT-related applications. Despite this clear requirement, many institutions still rely on single-factor authentication for certain access paths — particularly for RDP sessions to SWIFT operator PCs, database access to SWIFT-related databases, or administrative access to supporting infrastructure. Some institutions have deployed MFA for their primary SWIFT application login but have not extended it to all interactive access paths.
Remediation: Map every interactive access path to every SWIFT-related system and ensure MFA is enforced on each one. This includes RDP sessions, SSH connections, web-based administration consoles, and database management tools. Consider deploying a centralised MFA solution that can cover all access methods consistently.
4. Penetration Test Scope Excludes SWIFT Environment
The CSCF requires penetration testing that specifically targets the SWIFT environment. Many institutions conduct annual penetration tests as part of their general security programme, but the scope of these tests often excludes the SWIFT secure zone entirely — sometimes due to concerns about disrupting production messaging operations. An assessor will review the penetration test scope document and report to verify that SWIFT-specific systems were included.
Remediation: Ensure your annual penetration test explicitly includes the SWIFT secure zone in its scope. Work with your pen testing provider to schedule testing during maintenance windows if there are concerns about production impact. The test should cover network penetration testing, application-level testing of SWIFT interfaces, and privilege escalation attempts within the secure zone.
5. Incident Response Plan Not SWIFT-Specific
Many institutions have a corporate incident response plan that covers general security incidents but does not include SWIFT-specific scenarios. The CSCF requires that the incident response plan address scenarios relevant to the SWIFT environment — such as unauthorised SWIFT message submission, compromise of SWIFT operator credentials, or detection of malware on systems within the SWIFT secure zone. A generic corporate IR plan that mentions "critical systems" without specifically addressing SWIFT will not satisfy this control.
Remediation: Develop a SWIFT-specific annex to your incident response plan that includes SWIFT-related threat scenarios, escalation procedures to SWIFT's ISAC (Information Sharing and Analysis Centre), contact details for your SWIFT relationship manager, and procedures for isolating the SWIFT environment in the event of a confirmed compromise. Conduct at least one tabletop exercise per year using a SWIFT-specific scenario.
For institutions preparing for their first independent assessment, or those that have previously encountered control gaps, EIC offers a pre-assessment readiness review that identifies and helps remediate gaps before the formal assessment begins.
C H A P T E R 0 7
Choosing a SWIFT CSP Assessor — 6 Questions
Selecting the right assessor for your SWIFT CSP assessment is a decision that directly affects the quality of your assessment, the accuracy of your KYC-SA attestation, and the value you receive beyond the compliance exercise itself. Not all assessors bring the same level of experience, regional knowledge, or post-assessment support. The following six questions will help you evaluate potential assessors and identify the right fit for your institution.
1. Are you listed as an authorised SWIFT CSP assessor?
This is the baseline qualification. SWIFT maintains a directory of firms that meet its criteria for conducting independent CSP assessments. Ask the assessor to confirm their listing and provide evidence. Be cautious of firms that claim to be "SWIFT CSP capable" without being listed in SWIFT's official directory. While SWIFT does not issue a formal certification in the way that PCI SSC certifies QSAs, the listing in the directory is the recognised indicator of authorisation.
Red flag: The assessor cannot provide evidence of their listing in SWIFT's assessor directory, or they conflate general cybersecurity certifications with SWIFT-specific authorisation.
2. How many SWIFT CSP assessments have you completed?
Experience matters. An assessor who has completed a substantial number of assessments will have a much deeper understanding of common control gaps, practical implementation approaches, and the nuances of different SWIFT deployment models. Ask for a specific number and context — how many assessments in total, over what time period, and in which countries or regions.
Red flag: The assessor provides vague answers ("several" or "many") without specific numbers, or their assessment experience is concentrated in a single market with no exposure to your region.
3. Which architecture types have you assessed?
Different architecture types present different assessment challenges. An assessor experienced with A1 environments may not have the same depth of knowledge for A3 or A4 shared-responsibility scenarios. Ensure the assessor has direct experience with your specific architecture type and can articulate the control scope differences and responsibility boundaries relevant to your deployment model.
Red flag: The assessor has only assessed one architecture type and yours is different, or they cannot clearly explain the control scope differences between architecture types.
4. Do you provide remediation guidance when gaps are found?
Some assessors take a purely audit-oriented approach — they identify gaps and report them, but offer no guidance on how to address them. A good assessor will provide practical, actionable remediation recommendations that your team can implement. This is particularly valuable for institutions undergoing their first independent assessment or those with limited in-house SWIFT security expertise.
Red flag: The assessor explicitly states that remediation guidance is out of scope, or their assessment reports contain only pass/fail findings without context or recommendations.
5. Can you reference two clients in our region?
Regional experience brings practical benefits. An assessor familiar with the regulatory landscape, banking infrastructure, and common technology stacks in your market will be more effective than one assessing in your region for the first time. Ask for client references — with permission from those clients — from institutions in your country or a neighbouring market with similar characteristics.
Red flag: The assessor has no clients in your region or cannot provide any references at all, citing blanket confidentiality for all engagements.
6. How do you handle a control failure during assessment?
Understanding an assessor's approach to control failures reveals their professional maturity. A constructive assessor will immediately communicate findings to the institution, provide remediation guidance, and offer a reasonable window for the institution to address the gap before the assessment report is finalised. The assessor should be transparent about how control failures are documented in the assessment report and what options are available — including whether a partial re-assessment is possible if remediation is completed before the attestation deadline.
Red flag: The assessor takes a rigid pass/fail approach with no communication until the final report, or they suggest that control failures can be "worked around" in the attestation.
About EIC:EIC is an authorised SWIFT CSP assessor with 15+ completed assessments across seven Asia-Pacific countries. We assess all five architecture types and provide practical remediation guidance as part of every engagement. Our assessors hold CREST, CISA, and ISO 27001 Lead Auditor certifications and have hands-on experience with Alliance Access, Alliance Lite2, and regional service bureau environments.
Ready to start? Schedule a SWIFT CSP scoping call to confirm your architecture type, discuss your timeline, and receive a detailed assessment proposal.