Every year, compliance officers, treasury heads and operations managers at Saudi banks ask the same question: of all the controls in the SWIFT Customer Security Controls Framework (CSCF), which ones are we actually required to meet? This guide explains how to read SWIFT CSCF mandatory controls 2024 against your own connectivity model, and how to prepare for attestation without treating every control as equal.
Why the number is not fixed
The CSCF is published by SWIFT and sets the security baseline for the local environment of every SWIFT user. It is divided into mandatory controls, which must be implemented and attested, and advisory controls, which SWIFT recommends as good practice. Which controls are mandatory is not the same for every institution. It depends on your architecture type, which describes how far your own infrastructure extends into the SWIFT messaging chain.
Readers will see the figure of twenty-two mandatory controls quoted in discussions of the framework. Treat any single number with care. The mandatory set shifts with the framework version and with your architecture type, and you should confirm it against the current CSCF documentation published by SWIFT. The principle is stable: your architecture type defines your scope, and scope defines your obligations.
Three common architecture patterns
Direct connectivity
An institution that operates its own messaging interface and communication interface, on its own infrastructure, carries the widest scope. The secure zone, the operator accounts, the messaging software, the database and the connection to the network are all yours to protect. Expect the full mandatory set, including controls on environment segregation, privileged account management, patching, logging and monitoring, and incident response.
Shared infrastructure or service bureau
Where a service provider hosts part of the SWIFT stack, responsibility is divided, not removed. The provider attests for what it operates, but you remain accountable for what you control: your users, your workstations, your connection to the provider and your own processes. The common mistake is assuming the provider's attestation covers the institution. Auditors increasingly ask for evidence of how the split was agreed and how you verify it.
Alliance Lite2
Alliance Lite2 is a lighter connectivity option, and its in-scope footprint is smaller. Many infrastructure controls sit with SWIFT. That does not make the exercise trivial. User access, credential handling, workstation hygiene, and the operational controls around who can create and release messages remain with the bank and are frequently where gaps appear.
How the mandatory controls group together
Whatever the pattern, the mandatory controls fall into a few themes that map to the framework's own objectives:
- Restrict internet access and protect critical systems from the general IT environment, through segregation and tight control of administrative access.
- Reduce attack surface and vulnerabilities, through hardening, patching, secure data flows and integrity of software.
- Physically secure the environment, including the handling of personnel and devices.
- Manage identities and segregate privileges, with strong authentication and controlled operator accounts.
- Detect anomalous activity in systems and transaction patterns.
- Plan for incident response and information sharing, including tested procedures.
The practical test for each is whether you can show evidence, not whether a policy exists.
Advisory controls are becoming baseline
SWIFT has historically promoted some advisory controls to mandatory status in later versions of the framework. Auditors and counterparties know this. Controls on areas such as vulnerability scanning, transaction business controls, and staff awareness are increasingly treated as expected practice even where they are not yet mandatory for your type. For Saudi institutions, there is a second reason to take them seriously: the SAMA Cyber Security Framework already sets expectations for many of the same disciplines, so work done once can serve both.
A sensible rule is to treat advisory controls as a planning backlog. Implement those that are inexpensive and clearly reduce risk now, and record a reasoned decision for the rest.
Usual gaps
Across SWIFT environments, the same weaknesses recur:
- Scope defined informally, with components such as jump servers or administrator workstations missing from the inventory.
- Architecture type chosen by habit, not confirmed against the current definitions.
- Reliance on a service provider's attestation with no record of the shared responsibility split.
- Privileged and operator accounts reviewed rarely, or without evidence of the review.
- Logging enabled, but no one reviewing it and no documented escalation path.
- Incident response plans that never include a SWIFT-specific scenario.
- Evidence assembled in the final weeks before attestation, not held continuously.
A sensible order of work
- Confirm the architecture type. Everything else depends on it. Document the reasoning.
- Define scope. List every in-scope component, user and data flow, including those owned by providers.
- Assess each mandatory control with evidence. Record the result as implemented, partly implemented or not implemented, and attach the proof.
- Review advisory controls. Decide which to adopt and which to defer, with a rationale.
- Plan and close gaps. Prioritise by risk and by how close each item is to attestation.
- Prepare the attestation. Assemble the evidence, obtain internal sign-off and keep the file ready for independent review.
How we support this work
Our SWIFT CSCF Assessment & Attestation service follows the same sequence. We independently assess your SWIFT environment against the current Customer Security Controls Framework, identify gaps and support remediation and your annual attestation. The work runs in four stages: scope the architecture type and in-scope components, assess each control with evidence, support gap closure, and produce the final report for the attestation.
The service covers architecture type confirmation, assessment of mandatory and advisory controls, evidence documentation, remediation support and attestation preparation. The assessment phase takes 3–5 weeks. You receive an independent assessment report, a control-by-control evidence file and a gap remediation plan. The frameworks in scope are SWIFT CSCF and SAMA CSF.
Where the findings point to design weaknesses, such as segmentation or identity, our Security Architecture Review can be used to recommend practical improvements. Where your audit committee wants assurance alongside the attestation, our Internal Cybersecurity Audit service can be performed on behalf of, or alongside, your internal audit function.
Next step
If you are unsure which architecture type applies to you, or you want a clear view of your gaps before the next attestation cycle, begin with a scoping conversation. Confirming the type is a short exercise, and it makes every later decision easier to defend.
