Every bank connected to SWIFT attests annually against the Customer Security Controls Framework. Most treat it as a form-filling exercise until the first time a counterparty, or the central bank, asks to see the evidence behind the attestation.
What the CSCF actually asks
The framework's mandatory controls reduce to three questions. Can an attacker who compromises your general IT estate reach your SWIFT infrastructure? Would you detect them if they did? And could they submit or alter a payment message without a second pair of eyes? Everything else (segmentation, privileged access, integrity monitoring, anomaly detection) exists to make those answers defensible.
Where attestations go wrong
The most common failure we see is not a missing control but an unsupportable one: a bank attests "in place" based on intent rather than evidence. When an independent assessment is commissioned later, the gap between the attestation and reality becomes a board-level problem, because the attestation is a formal statement to SWIFT and, increasingly, to supervisors.
The second failure is scoping. Banks draw the secure zone around the messaging interface and forget the operator PCs, the jump hosts, and the backup infrastructure that can reach it.
Sequencing the work
A realistic program for a mid-size bank runs eight to twelve weeks: scope confirmation and architecture review first, then a gap assessment against the current CSCF version, then remediation in two sprints (quick configuration wins, then structural changes like segmentation), and finally evidence collection aligned to each control objective. Run it to finish at least a quarter before your attestation deadline so remediation is not competing with the submission date.
Independent assessment is now the norm rather than the exception. Choose an assessor who will test the controls, not just interview the owners; the point of the exercise is to know your answer is true before you sign it.