SWIFT CSP Compliance Checklist: The Essential 2026 Guide to CSCF v2026 Controls

A SWIFT CSP compliance checklist is a step-by-step list of what a SWIFT user must do each year under the Customer Security Programme: work out which controls apply, implement them, collect evidence, arrange an independent assessment and submit an attestation. The controls come from the Customer Security Controls Framework, known as the CSCF.

CSCF v2026 contains 32 controls organized under three objectives and seven principles. Of these, 26 are mandatory and 6 are advisory in the 2026 cycle, after control 2.4 on back office data flow security moved from advisory to mandatory. Which controls apply to you depends on your architecture type.

This guide is a planning aid, not a substitute for the framework or for Swift’s published instructions. Check the current documents on the Swift site before you finalize your scope and dates.

Who needs a SWIFT CSP compliance checklist

Every institution that uses the SWIFT network must take part in the programme and attest annually to its compliance with the mandatory controls. That includes banks, corporates, market infrastructures and service bureaus. Your attestation is visible to counterparties, who use it in their own third-party risk assessment.

The obligations are not optional. The consequences of non-compliance, including reporting to supervisors, are covered in SWIFT CSP non-compliance. Because the attestation is shared, a late or weak submission can affect your counterparties’ view of you.

The checklist is especially useful for smaller users, which often have no dedicated SWIFT security team. It turns the framework into a list of tasks with owners.

Step one: determine your architecture type

The framework classifies users by how they connect: A1, A2, A3, A4 or B, based on where the messaging and connector components sit. The classification decides which controls are mandatory for you and which are advisory, so getting it wrong leads to an incorrect scope. See SWIFT architecture types.

Draw a diagram of the components and data flows: the messaging interface, the communication interface, the graphical user interface, connectors, the local SWIFT infrastructure and any service bureau. Include the workstations and the people who operate them.

Record the classification and get it approved by an appropriate manager. Changes in infrastructure, such as moving to a service bureau or a cloud-based connector, may change the type, so revisit it each year.

Step	Action	Output
1	Identify architecture type (A1, A2, A3, A4 or B)	Scope statement
2	Map applicable mandatory and advisory controls	Control applicability list
3	Implement and document controls	Policies, configurations
4	Arrange independent assessment	Assessment report
5	Submit attestation in KYC-SA	Attestation record

Step two: map the controls in CSCF v2026

Take the current CSCF and list each control with its applicability for your type. The framework is organized around three objectives: secure your environment, know and limit access, and detect and respond. The overview in SWIFT CSCF explains the structure, and CSCF v2026 covers the version changes.

Note the new status of control 2.4. If you previously treated it as advisory, update your scope and plan for implementation. The complete set of mandatory requirements is described in SWIFT mandatory controls.

For advisory controls, record a decision. Even if you do not attest to them, Swift recommends implementing them, and many institutions adopt them as good practice.

Step three: implement and evidence the controls

For each applicable control, record how you meet it, who is responsible, what evidence demonstrates it and when it was last verified. Typical areas include the secure zone around SWIFT components, operating system and application hardening, patching, multi-factor authentication and privileged access, logging and monitoring, and incident response. See SWIFT secure zone for the architecture expectations.

Evidence should be dated and reproducible: configuration exports, access lists, patch reports, log samples, test results and approved policies. A screenshot with no date is weak evidence.

Close the gaps. Assign each missing or partial control to an owner with a deadline and a compensating control where needed, and note the decision in the plan.

Step four: independent assessment

Swift requires an independent assessment of your compliance, carried out either by an internal function independent of the first line, such as internal audit or risk, or by an external assessor. The details are in SWIFT CSP independent assessment.

Choose the assessor early and share the scope and evidence in advance. Agree how findings will be reported and how disagreements will be resolved. The cost depends on architecture, number of environments and whether you use external help, as discussed in SWIFT CSP assessment cost.

Allow time for remediation. Findings discovered near the deadline can leave no room to fix issues before the attestation is due.

Step five: submit the attestation

The attestation is submitted through the KYC Security Attestation application, known as KYC-SA. It records your architecture type, your compliance status against each control and details of the independent assessment. See KYC-SA and SWIFT CSP attestation for the steps.

Check the current submission window on the Swift site, and aim to submit well before it closes. The Customer Security Programme page at Swift Customer Security Programme describes the journey and support resources.

Keep a copy of everything submitted, including the assessment report and the evidence index, and brief senior management on the result. A named executive should approve the attestation.

Common mistakes with a SWIFT CSP compliance checklist

The first mistake is scoping wrongly by ignoring a service bureau or a forgotten workstation. The second is treating the attestation as a yearly form instead of a continuous control set, which leads to a scramble before the deadline. The third is weak evidence: controls may exist, but without dated proof an assessor cannot confirm them.

The fourth is assuming that a service provider carries your responsibility. Even where a bureau operates components for you, you remain accountable for the controls that apply to your use. Get written confirmation from the provider about which controls it covers.

Finally, do not ignore changes during the year. New users, new tools or a change in architecture can alter your compliance status without anyone noticing.

A short SWIFT CSP compliance checklist example

A regional bank with an A1 architecture reviews its checklist in the second quarter. It finds that privileged access to the SWIFT servers relies on shared accounts, so multi-factor authentication and individual accounts are missing. It also finds that patch reports for the secure zone exist only for one of two servers.

The team implements individual admin accounts with multi-factor authentication, fixes the patch reporting and records new evidence. It books the independent review for the fourth quarter, leaving six weeks for any further fixes. The scenario is invented, but it shows why the SWIFT CSP compliance checklist should start months before the attestation date.

The result is a clean attestation and a documented plan for the advisory controls.

Building the SWIFT CSP compliance checklist into your annual calendar

Treat the programme as a yearly cycle with fixed milestones. In the first quarter, confirm the architecture type and review the new CSCF version. In the second and third quarters, implement changes, refresh evidence and run internal checks. In the fourth quarter, complete the independent assessment, fix findings and submit the attestation ahead of the deadline. Put each milestone on a shared calendar with a named owner.

Hold a short monthly review during the year. The agenda is simple: what changed in the SWIFT environment, which controls are at risk, which evidence is about to expire and which findings are still open. A SWIFT CSP compliance checklist that is reviewed monthly rarely produces surprises at year end.

Finally, keep senior management informed. A one-page status showing controls met, controls partial, and planned dates gives executives enough information to approve resources and to sign the attestation with confidence.

Evidence index for a SWIFT CSP compliance checklist

Create one table listing every applicable control, the evidence file name, the date collected, the owner and the reviewer. Store the files in a single controlled folder with read-only access for assessors. When the independent assessor requests proof, you can respond quickly and consistently, which lowers cost and reduces disagreements about what was in place at the time of review.

Refresh evidence when configurations change, not just once a year. For controls that operate continuously, such as logging and monitoring, add periodic samples so the assessor can see the control operating over time instead of a single snapshot.

Using a ready-made SWIFT CSP compliance checklist

Creating the policies, procedures, evidence trackers and assessment packs from scratch is slow. A prepared set of documents gives you a base to adapt to your architecture.

The SWIFT CSP Toolkit provides 32 editable templates aligned to CSCF v2026, covering the secure zone, access control, network segmentation, cryptography, logging, vulnerability management and more. Map each template to a control and record the owner.

Start with scope and the evidence index, since every other step depends on them.

SWIFT CSP compliance checklist FAQ

How many controls are in CSCF v2026?

CSCF v2026 has 32 controls, of which 26 are mandatory and 6 advisory in the 2026 cycle, depending on architecture type.

Is an independent assessment required?

Yes. Swift requires an independent assessment by an internal independent function or an external assessor, and the results support your attestation.

Where is the attestation submitted?

Through the KYC Security Attestation application, KYC-SA.

What happens if we are non-compliant?

Your status is visible to counterparties, and Swift may report non-compliant users to their supervisors, so prompt remediation is important.

Does a service bureau remove my obligations?

No. You remain responsible for the controls that apply to your use, even if a provider operates part of the infrastructure.