SWIFT CSP non-compliance does not switch off your connection to the network, but it does make your gaps visible to your supervisor and to the banks you trade with. That visibility is the real consequence, and it is enough to cost business, trigger regulatory questions and force an urgent remediation project.
This guide explains what SWIFT reports, who can see it, how a failed control differs from a missing attestation, and how to build a recovery plan that will stand up in front of a supervisor. For the yearly process itself, see our SWIFT CSP attestation guide.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
What SWIFT CSP non-compliance actually means
Under the Customer Security Programme, each user must attest to its compliance with the mandatory controls of the Customer Security Controls Framework, and must re-attest at least once a year. Swift’s own guidance describes several categories of user that it reports on: those without a valid attestation, because none was submitted or it has expired; those not compliant with the mandatory controls; those that did not perform an independent assessment; and those connecting through a service provider that is itself non-compliant.
These are different problems with different fixes. A missing attestation is an administrative failure that submission cures. A failed mandatory control is a security gap that needs engineering work. A missing independent assessment is a governance gap. Keep them separate in your remediation plan so each gets the right owner.
| Category | Typical cause | Fix |
|---|---|---|
| No valid attestation | Missed the deadline, or the attestation expired | Submit within the July to December window |
| Non-compliant with mandatory controls | One or more controls not implemented | Remediate, then update the attestation |
| No independent assessment | Assessment skipped or not independent | Commission an internal or external assessor who is independent of the operation |
| Non-compliant service provider | Provider fails its own controls | Obtain assurance, or change provider |
Who sees SWIFT CSP non-compliance
Swift states that non-compliance is reported and made visible in a dedicated real-time application available to the customer’s supervisor. Attestation data is also shared with counterparties through the attestation application, so a bank considering a new correspondent or a client can see your status. Commentary from advisers adds that Swift reserves the right to report to both supervisors and counterparties, which is why the reputational effect often arrives before any regulatory one. Our KYC-SA guide shows how counterparties consult that data.
Is your access to the network at risk?
Swift’s published approach is transparency rather than automatic disconnection, and advisers generally state that a non-compliant user is not removed from the network on that ground alone. Failing to submit an attestation at all, however, breaches the contractual terms you accepted as a user. Treat suspension as a remote risk, but do not rely on that: your supervisor may set its own expectations for institutions it regulates.
The deadline and validity rules behind SWIFT CSP non-compliance
Attestations must be submitted by 31 December, and users re-attest at least annually, with the submission window running from July to December. New users attest before going live. Because the attestation is a statement of your position on that date, an attestation that discloses gaps still counts as an attestation. Submitting late, or not at all, is worse than submitting an honest partial one.
Read the current control set before you attest. The changes in the latest framework version are summarised in our CSCF v2026 guide, and the split between mandatory and advisory items is in SWIFT mandatory controls vs advisory.
Why the independent assessment matters
The framework requires an independent assessment of your attestation, and a user that skips it is reported as such. The assessor can be internal, provided it is independent of the team that operates and secures the environment, or external. Our article on SWIFT CSCF independent assessment explains when an internal function qualifies. A clean attestation with no independent challenge is a weak position in a supervisory meeting.
Service providers and third parties
You remain responsible for the assessment even when a provider hosts part of your SWIFT infrastructure. Advisers describe the expectation that you obtain assurance on your providers, such as an independent assessment or a recognised report covering the relevant controls, and that it is reasonably recent. A provider’s certificate for a different scope does not help you if it does not cover the controls in question, so read the scope statement before filing it as evidence.
A recovery plan for SWIFT CSP non-compliance
When you find a gap, a supervisor will want to see a plan and not a promise. A workable plan has these parts.
- Confirm the gap. Identify the exact control and the part of the architecture where it fails.
- Assess the risk. Explain what an attacker could do while the gap remains, and what compensating measures already exist.
- Set actions, owners and dates. Break the fix into tasks with a named owner and a date for each.
- Attest honestly. Declare the non-compliance in the attestation instead of waiting until it is fixed.
- Report progress. Give senior management and, where expected, your supervisor a regular update.
- Verify the fix. Retest, and keep the evidence for the next independent assessment.
- Update the attestation. Change the attested status once the control is operating.
Common mistakes when handling SWIFT CSP non-compliance
Institutions tend to leave the attestation to the last week of December. They attest as compliant on the strength of a policy, without testing that the control works. They treat the assessment as a formality. They forget that a control failing at a provider is still a failure for them. Or they hide a gap from the board until a counterparty asks about it. Each of these turns a fixable technical issue into a governance problem.
A hypothetical example of handling a failed control
Suppose a mid-sized bank finds in September that its operator accounts on the messaging interface do not meet the multi-factor authentication expectation, because a legacy jump server still uses passwords alone. The security team estimates a fix in eleven weeks. The bank does not wait. It records the gap in its risk register, adds compensating measures such as tighter network rules and enhanced logging on that server, informs the head of operations and the risk committee, and files its attestation in November with the control marked as not yet compliant and a dated remediation plan attached. In February, after the fix is live and retested, it updates the attested status and stores the test evidence for the independent assessor. The example is illustrative only.
What makes it work is sequence and honesty. The bank found the problem itself, put a date on it and told the people who needed to know, so a supervisor reading the status sees an institution in control of its risk.
Board and management reporting
SWIFT CSP non-compliance should not surface first in a supervisor’s letter. Give senior management a short, regular view: the attestation date and status, the number of mandatory controls fully compliant, open gaps with owners and dates, the state of the independent assessment, and any service provider concerns. One page each quarter is enough. If a gap is likely to remain open across an attestation cycle, escalate it, and record who accepted the residual risk and on what basis.
Link the programme to your wider risk framework too. A gap in the secure zone or in operator authentication is a payment fraud risk as well as a compliance finding, and it belongs in the enterprise risk register with the same discipline as other operational risks.
Evidence to keep ready for the next cycle
Keep an evidence pack throughout the year and not only at attestation time. It should hold the architecture diagram and the architecture type you selected, the control-by-control assessment with the evidence reference, configuration screenshots or exports, access review records, vulnerability scan results and patch records, the independent assessor’s report, the remediation tracker with closure evidence, and provider assurance documents. A supervisor or counterparty asking a question about SWIFT CSP non-compliance months after the attestation can then be answered from records rather than recollection.
Reducing SWIFT CSP non-compliance with ready-made documents
Much of the effort is evidence: policies, procedures, control descriptions, assessment workpapers and remediation trackers that map to each control. The SWIFT CSP Toolkit provides templates for these, which you can tailor to your architecture type. For the official position, read Swift’s security attestation page, and check it again before each attestation cycle, since details can change.
SWIFT CSP non-compliance FAQ
Will SWIFT disconnect me if I am non-compliant?
Swift’s stated approach is reporting and visibility, not automatic disconnection, but failing to attest breaches your contractual obligations, and your supervisor may act on what it sees.
Who can see that I am non-compliant?
Your supervisor, through a dedicated application, and your counterparties, through the attestation directory.
Can I attest if I am not fully compliant?
Yes, and you should. An honest attestation that declares gaps is better than no attestation.
When must I attest?
By 31 December each year, with the submission window opening in July, and before going live for new users.