Banks that reach SWIFT through a service bureau rather than their own infrastructure tend to assume that SWIFT’s customer security framework is someone else’s problem. It is not. The scope is smaller, but the controls that remain are the ones that matter most.
The situation
A challenger bank connected to the SWIFT network through a service bureau. Its annual independent assessment under the Customer Security Controls Framework was due, and the bank wanted it done properly rather than as a self-attestation nobody had checked.
The decision that sets the scope
Everything in this framework depends on one early choice: the architecture type. Pick the wrong one and you assess the wrong controls. With a service bureau and no local SWIFT software, the right answer was the type with no local user footprint. That made the scope a single operator virtual machine in the bank’s cloud environment, reached over VPN and remote desktop, plus the people who used it and the tokens they held.
We settled that first, with a diagram, before looking at a single control. Two days were then enough for the assessment itself.
What was in place
More than people expect from a small bank. A full inventory of SWIFT tokens, with serial numbers and hand-over dates. Twenty-four character passwords. A password vault run by one named security officer. Awareness training every six months. An incident response plan that had visibly been used on real events, not written for the assessment.
What was not
Two of the fifteen mandatory controls assessed were not in place, and both sat on the one machine in scope. The operator virtual machine could browse the Internet freely, and nobody reviewed its security event logs. A general-purpose machine with open browsing is exactly what the framework’s restrictions on the operator environment exist to prevent, and a machine nobody watches is a machine nobody will notice being misused.
Both were cheap to close: allow-list the browsing, and put the machine’s logs in front of someone with a schedule.
The deliverables were the assessment report, the framework’s own evaluation forms, and a completion letter the bank could attest with.
In an outsourced model, the operator workstation is the SWIFT environment.
What people get wrong
They assume the framework does not apply once SWIFT is outsourced. The service bureau runs the SWIFT software. The bank still has an operator, a workstation, tokens and a process, and those are in scope.
They pick the architecture type casually. It is the single most consequential decision in the assessment, and it is usually made by whoever filled in the form last year.
They harden the data centre and forget the operator’s PC. In an outsourced model the operator workstation is the SWIFT environment.