How the SWIFT CSCF attestation cycle works for your organization
Your deadline is 31 December 2026. CSCF v2026, published by Swift in July 2025, is the version Swift users attest against between July and December 2026, and attestations are submitted in the KYC-Security Attestation (KYC-SA) application. Swift's rule is that users attest no later than 31 December and re-attest at least annually, so the window is a yearly obligation rather than a one-time project. The cycle itself is the same for every Swift user. What differs is the amount of work: the controls in scope depend on your architecture type, how much of the evidence you already hold, and what the independent assessment finds. Confirm your architecture type early, because it sets the control list your team will be measured against.
Responsibilities split three ways. Your organization owns the attestation and is accountable for the statements made in it. The independent assessor, whether an internal function such as risk, compliance or internal audit, or an external firm, tests the controls and supports the attestation, because every attestation must be backed by an independent assessment. Swift reviews submissions and can report users whose attestation is missing or non-compliant. If you use an implementation partner to prepare systems and evidence, that partner does not sign the attestation or issue the assessment. Ask who on your side will sign, who will assess, and who will hold the evidence before the window opens.
Swift publishes each CSCF version a year before it applies and gives users up to 18 months to prepare for new or changed controls. Use that preparation period to close gaps before the July window opens, rather than starting in December. Where a control is not yet met, you indicate a remediation date in the attestation and update it once the control is compliant, so a documented remediation plan is a legitimate path, but it should be realistic and tracked. Put the annual re-attestation on your calendar as a recurring task with a named owner, and check the Swift Customer Security Controls Policy and the Independent Assessment Process Guidelines for the current rules before you commit to a date.
What happens each year in the SWIFT CSP cycle
The yearly sequence turns a published CSCF version into an independent assessment, a submitted attestation and, where controls are still open, a dated remediation plan. Each phase leaves a record that the next phase depends on, and the cycle repeats at least annually.
Swift publishes the next CSCF version
Each July Swift publishes a new version of the Customer Security Controls Framework, and that version takes effect a year later. The current cycle covers CSCF v2026, published in July 2025, which Swift users attest against between July and December 2026. Swift's Understand controls page sets out this publication cadence, so the first task is to confirm which version applies to your attestation year. The output is a documented decision on the controls version in scope, recorded against your architecture type and your list of mandatory and advisory controls.
Access the new controls version in KYC-SA
In early July, the KYC-Security Attestation (KYC-SA) application makes the new controls version available for attestation. The Swift user's security or compliance owner should confirm the version and the controls list in the application before any internal work starts. The output is a confirmed control set for the attestation year, which becomes the baseline for the gap analysis and the independent assessment.
Close gaps and implement controls
The organization compares its current environment with each in-scope control and implements what is missing or weak. Ownership sits with the Swift user, even when an internal team or an implementation partner does the technical work. Where a control cannot be met before the attestation is made, the user records a remediation date for it. The output is a control-by-control status view with evidence for each control that is met and a dated plan for each that is not.
Complete the independent assessment
Every attestation must be supported by an independent assessment. The assessor may sit in a second or third line function, such as risk, compliance or internal audit, or may be external to the organization. Swift's CSP Assessor Certification is optional. The assessor tests the controls against the evidence and records the results. The output is a signed assessment report that supports the attestation and that the organization can present if asked.
Submit the attestation in KYC-SA
The Swift user submits its attestation in KYC-SA between 1 July and 31 December of the attestation year. Mandatory controls must be met for the attestation to be compliant, while any control not yet met is shown with a remediation date. The attestation is the formal record Swift and permitted counterparties see. The output is a submitted attestation with a date, a named responsible person and a remediation date for each open control.
Update the attestation after remediation
When a control moves from not met to met, the user updates the attestation to reflect the change. Remediation dates should be tracked as work items with owners, so the update is triggered by evidence rather than by the calendar. The output is an updated attestation record and a closed remediation item, with the new assessment evidence stored alongside the original report.
Re-attest at least once a year
Users must re-attest at least annually, so the cycle restarts when the next version becomes available. Re-attestation does not carry forward the previous year's position automatically, because the controls version and the environment may both have changed. The output is a current attestation for the new cycle, backed by a fresh independent assessment, and a clear list of what changed since the previous year.
What new joiners must do before going live
New joiners must attest before they go live on the Swift network. A new Swift user does not wait for the normal July to December window to submit its first KYC-Security Attestation (KYC-SA). The attestation has to be in place before live messaging starts, and it must be backed by an independent assessment, because Swift requires every attestation to be supported that way. Plan the assessment and the attestation as prerequisites on the go-live critical path, not as tasks to finish after launch.
The first attestation still uses the CSCF version that is current when you submit it. For the CSCF v2026 cycle, that means the v2026 controls apply to attestations due between July and December 2026. Because a new version is published every July and takes effect a year later, a joiner whose go-live date falls near a version change should confirm with Swift which controls version the KYC-SA application will accept on that date. Also confirm which architecture type applies to your connection, since that determines which controls are in scope for the assessment you commission.
Before you schedule go-live, check three things in the KYC-SA application: the controls version it offers for your submission, the deadline it shows for your attestation, and whether any control is not yet met. If a control is not yet met, you can indicate a remediation date and update the attestation once the control is in place. Keep that remediation plan realistic and documented, because an open gap at go-live is still a gap Swift can see. Your supervisors may also see reported non-compliance, so treat the first attestation as a formal milestone with an owner and a sign-off.
What happens when an attestation is missing or non-compliant
Swift reserves the right to report a user for five distinct gaps in its attestation cycle, and the consequences reach beyond Swift itself. Reported non-compliance is visible to the user's supervisor, and attestations that are published can be read by counterparties who have been granted access. Check each trigger before the December deadline, not after Swift raises it.
No valid attestation
A user with no valid attestation can be reported to Swift's oversight. For a new joiner, the attestation must be completed before going live on the Swift network, so a late attestation can delay connection. For an existing user, the attestation must be submitted by 31 December of the attestation window and refreshed at least once a year. Confirm the attestation date, the submitting officer, and the calendar for the next re-attestation before the window opens in early July.
Non-compliance with mandatory controls
Mandatory controls must be met, and an attestation that shows a mandatory control as not met is a reportable condition. If a control is not yet met, the user indicates a remediation date and updates the attestation once the control is in place. Map each mandatory control in your architecture type to a named owner and a dated remediation plan, and keep the plan consistent with what the attestation states.
No independent assessment
Every attestation must be supported by an independent assessment, so an attestation without one is reportable even when the self-declared answers look sound. The assessment may be internal, performed by a second or third line function such as risk, compliance or internal audit, or external. Confirm that the assessor is independent of the team that implemented the controls and that the assessment covers the same CSCF version as the attestation.
Non-compliant service provider
A user can be reported when a service provider it relies on is not compliant. This matters most for users who connect through a service bureau or use shared infrastructure, where the user's attestation depends on the provider's position. Ask each provider for its current attestation status and its assessment evidence, and record what happens to your attestation if a provider falls out of compliance during the year.
Incomplete Swift-mandated external assessment
Where Swift requires an external assessment, an assessment that is started but not completed is reportable in its own right. Incomplete work can leave gaps that look like compliance on paper but cannot be relied on. Agree the assessment scope, the assessor and the completion date in writing early in the window, and confirm with the assessor when the report will be final and ready to support the attestation.
Visibility to supervisors and counterparties
Reported non-compliance appears to the user's supervisor in a dedicated real-time application, so a report is a supervisory matter as well as a Swift one. Published attestations can also be viewed by counterparties that have been granted access for their third-party risk management. Decide in advance who answers supervisor and counterparty questions, and check the attestation policy in the Swift Customer Security Controls Policy for the current reporting rules before you submit.
What to do when a mandatory control is not yet met
When a mandatory control is fully implemented and an independent assessment has confirmed it, the attestation can be submitted with that control marked as compliant. The organization is responsible for the accuracy of every answer, and the assessment behind it must support what is declared. Confirm the evidence before submission, not after, because the attestation is a statement the organization signs for.
- Match the answer to the assessed state: Mark a control as compliant only when the assessment tested the current configuration, not a planned one.
- Keep evidence dated and traceable: Store configuration exports, access reviews and logs that show the control operating at the time of assessment.
- Recheck after change: A later change to a platform, its hosting or its access model can make a previously compliant answer inaccurate.
- Align with the assessor's scope: Confirm that the systems and architecture type covered by the assessment match the attestation.
- Re-attest on time: Submit before 31 December of the attestation window and re-attest at least annually.
Before submitting, check that every compliant answer maps to assessment evidence dated within the attestation period.
If a mandatory control is not yet met, the attestation process allows the user to indicate a remediation date for that control. The remediation plan, its owner, its milestones and the target date are set by the organization. An implementation partner or internal team can build the controls and prepare evidence, but the attestation itself is submitted and maintained by the Swift user. Treat the remediation date as a commitment that the organization must be able to defend to its supervisors and counterparties.
- Name an accountable owner: Assign one executive or manager who signs off the remediation plan and tracks progress.
- Break the gap into steps: Document the interim measures, the configuration work, the testing and the evidence each step will produce.
- Set a realistic date from your own plan: Derive the date from work already scheduled and resourced, and confirm lead times with vendors and hosting providers.
- Record the gap in your risk register: Note the unmet control, its residual risk and any compensating measures in use.
- Plan the independent assessment: Schedule the assessor to test the control once it is implemented so the later update has supporting evidence.
Confirm that the remediation date appears in your own governance records and that the owner can explain the plan without referring to the vendor.
Once the remediation work is complete, the user must update the attestation to show the control as compliant. This update should only be made after the control has been independently assessed in its implemented state. Until the update is made, the attestation continues to show the control as open with its indicated date, so the record should reflect the actual status at every point in time.
- Verify before updating: Obtain assessment evidence that the control operates as described before changing the status.
- Update the attestation yourself: Only authorized users in the organization can make the change in the KYC-Security Attestation application.
- Retain the timeline: Keep records of the original remediation date, the completion date and the assessment that confirmed it.
- Inform affected teams: Let compliance, risk and counterparty management teams know when a previously open control closes.
- Do not backdate: Evidence and status changes must show the date they were made.
Before updating, check that the assessment evidence covers the control in its current state and that the change record is complete.
What makes the attestation cycle harder or easier to meet
Most attestation delays trace back to a small set of drivers: which architecture applies, how many components and providers sit in scope, how mature last cycle's evidence was, who can perform the assessment, and how much time falls between the July release and the December deadline. Each driver can be planned for before the window opens, so review them early rather than in the final weeks.
Architecture type and controls in scope
Your architecture type (A1, A2, A3, A4 or B) decides which CSCF controls apply to you, so it sets the size of the whole exercise. Confirm the type against how your organization actually connects to Swift and who owns each component and licence. A type change during the cycle can add or remove controls mid-attestation, so record the decision and its rationale before you start the gap analysis. Check the architecture type again each July when the new controls version appears.
Connected components and service providers
Every connected component, interface and service provider widens the evidence you must produce. A non-compliant service provider is itself a reason Swift may report a user, so provider attestations and contract clauses belong in the plan. Build a current inventory of components, owners and providers, and confirm which provider obligations you can verify before December rather than assuming them.
Evidence maturity from the prior cycle
Evidence that was assembled from memory or screenshots last year usually takes longer to rebuild than to refresh. Review the previous attestation and its assessment file, note which controls relied on informal proof, and move those to repeatable records such as configuration exports, access reviews and change logs. Ask whether each control has a named owner who can produce its evidence on request, since missing owners are a common cause of slow closure.
Internal assessor availability
The independent assessment can be internal, performed by a second or third line function such as risk, compliance or internal audit, or external. Internal teams are only a shortcut if they have the time and independence in the calendar before the window closes. Confirm early which individuals will assess, whether they are free during the assessment period, and whether they are separate from the people who operate the controls. Decide whether an external assessor is needed for any gaps.
Lead time from July release to December deadline
The new CSCF version is published in July, and attestations against it are due by 31 December of the following year. The gap between those dates is the working window, and it shrinks quickly once reviews, remediation and assessment all compete for the same people. Treat the July release as the start of the plan: book the gap analysis, reserve assessor time and set internal checkpoints in the first weeks. Ask any partner to commit to dates in writing.
Who owns each part of the attestation
The Swift user is the accountable party. Its management and compliance team decide which architecture type applies, which controls are in scope, and whether each control is met today or needs a remediation date. The user submits the KYC-Security Attestation (KYC-SA) and is the entity whose supervisors can see any reported non-compliance. No vendor or consultant can sign or submit on its behalf.
- Architecture and scope: Confirm the architecture type that matches how the organization connects to Swift, since that choice sets the controls in scope.
- Control ownership: Assign a named owner to each control, including controls run by service providers the user relies on.
- Remediation decisions: Where a control is not yet met, record a remediation date and update the attestation once the control is compliant.
- Attestation submission: Submit in KYC-SA between July and December of the attestation year, and re-attest at least annually.
- Assessor engagement: Choose the assessor type (internal second or third line, or external) and confirm that the assessment supports the attestation before submission.
Ask your compliance team to confirm in writing who signs the attestation and who approves remediation dates.
An implementation partner helps the user build the environment and the evidence behind each control. It does not decide compliance and does not submit the attestation. Its work sits in the systems, configuration and documentation that the assessor later samples. DeployOpen works in this role for self-hosted platforms inside the client's own infrastructure, under a written, fixed scope.
- System preparation: Harden, configure and document the platforms and components that fall within the controls in scope.
- Evidence production: Prepare configuration exports, access records, logs and test results that show each control operating.
- Gap analysis input: Help the user identify where current systems fall short of the mandatory controls, so remediation dates reflect real work.
- Remediation delivery: Carry out agreed fixes under a written scope with deliverables and timelines.
- Independence limit: Do not perform the independent assessment of the same controls you implemented, and do not sign the attestation.
Ask any partner to state in writing which controls it implements, which it only documents, and which it has no role in.
Every attestation must be supported by an independent assessment. The assessor tests whether the controls in scope are implemented and operating. It may be a second or third line function such as risk, compliance or internal audit, or an external firm. Swift's CSP Assessor Certification is optional, so the user should not assume it is required, but it is a useful signal of assessor qualification.
- Internal assessors: Second or third line staff can assess if they are sufficiently independent of the people who run the controls.
- External assessors: An outside firm brings independence and can be the stronger choice where internal staff implemented or operate the controls.
- Optional certification: Swift's CSP Assessor Certification is optional. Ask whether the assessor holds it and what evidence supports their qualifications.
- Assessment output: The assessor's findings support the attestation, and any gaps must be closed or dated before the user attests.
- No attestation role: The assessor tests and reports to the user. It does not attest on the user's behalf.
Ask the assessor to confirm its independence from the implementation work and to explain how it will sample evidence.
Questions buyers ask about the SWIFT CSCF attestation cycle
When is the deadline for the current SWIFT CSCF attestation cycle?
Attestations covering CSCF v2026, published by Swift in July 2025, are due between 1 July and 31 December 2026. Swift publishes each new CSCF version in July, a year before it takes effect, and users attest in the window that follows. The attestation is submitted in the KYC-Security Attestation application, where the new controls version becomes available in early July. Users must attest no later than 31 December and re-attest at least annually. Confirm the exact window, portal dates and any changes for your cycle directly with Swift, because the operational calendar is set by Swift rather than by your auditor or partner.
What happens if a SWIFT attestation is missed or non-compliant?
Swift reserves the right to report users with no valid attestation, non-compliance with mandatory controls, no independent assessment, a non-compliant service provider, or an incomplete Swift-mandated external assessment. Reported non-compliance is visible to the user's supervisor in a dedicated real-time application, so the consequence is reputational and supervisory as well as administrative. If a mandatory control is not yet met, the user indicates a remediation date and updates the attestation once compliant. Treat the remediation date as a commitment you must be able to defend. Confirm the reporting process and escalation steps with Swift.
Do new SWIFT users need to attest before going live?
Yes. New joiners must attest before going live on the Swift network, and the attestation must be supported by an independent assessment. Existing users re-attest at least annually, so a new connection does not wait for the standard December deadline. Plan the assessment and the KYC-Security Attestation submission into the project plan before the production cutover, since an attestation that is not in place can delay go-live or trigger reporting. Confirm the current joiner requirements and any transition arrangements with Swift before you schedule the connection.
Can an outside partner submit the SWIFT CSCF attestation for us?
The organization owns its attestation. Submission is made by the Swift user in the KYC-Security Attestation application, and the attestation must be supported by an independent assessment that may be internal, performed by a second or third line function such as risk, compliance or internal audit, or external. An implementation partner can prepare systems, configuration evidence and documentation for the assessor, but it does not issue the attestation or the assessment conclusion. Confirm with Swift which roles may be delegated in the application and how the independent assessment must be documented.
How much internal effort does the SWIFT attestation cycle need?
Effort depends mostly on the number of controls in scope, the current state of the environment and how much evidence already exists. Scope is set by your architecture type, which determines which of the 32 CSCF v2026 controls apply, with 26 mandatory and 6 advisory. The main drivers are the gap between current configuration and each mandatory control, the number of systems and service providers in the Swift environment, the depth of the independent assessment, and how well change records and access reviews are kept. Recurring work includes re-attesting each year and tracking remediation dates. Ask any partner or assessor for a quote that lists the in-scope controls, systems, evidence items and recurring activities.
What does the SWIFT attestation cost, and who gets paid for what?
The cost has several components: internal staff time to implement and evidence controls, any remediation work on systems and configuration, the independent assessment (internal or external), any optional assessor certification, and ongoing support. Only the independent assessor and the internal team are paid for the assessment itself, while a partner is paid for implementation or evidence preparation under a written scope. Some costs are one-time, such as the initial gap analysis and remediation, while others recur each annual cycle. Ask for a quote that separates these items and states which controls, systems and deliverables it covers. DeployOpen does not publish a price list, and any quote follows from the written scope.
Can SWIFT counterparties see our attestation?
Published attestations are visible to counterparties that are granted access, which supports their third-party risk management. This means your attestation status is a commitment that business partners may review, so the content must match the evidence behind it. Decide which counterparties need access, keep the attestation accurate when controls change, and make sure your independent assessment can support any question a counterparty raises. Confirm the access mechanism and what each counterparty can view with Swift.
Where to confirm the cycle dates and rules
Before you plan an attestation, confirm the dates and rules against Swift's own pages rather than relying on secondary summaries, including this one. Start with the Swift CSP: Understand controls page, which sets out the annual publication of each CSCF version and the attestation window that applies to it. For the version you will attest against, the CSCF v2026 document is the controls reference itself. It is published behind a Swift login, so your security or compliance lead should download it from the Swift Knowledge Centre with a named account and keep the version reference in your attestation file.
For the mechanics of submission, use the Swift CSP: Submit KYC-Security Attestation page, which describes the KYC-SA application, the timing of each new controls version in early July, and the deadline for re-attestation. The Swift Customer Security Programme overview page covers the programme as a whole, including how remediation dates work when a control is not yet met and how published attestations are shared with counterparties. Check which of your staff hold KYC-SA access before the window opens, since access requests can take time to process.
Two governing documents set the attestation policy and process: the *Swift Customer Security Controls Policy* and the *Independent Assessment Process Guidelines*. The web pages summarize them, but the policy and guidelines are the texts that define what counts as a valid attestation and a valid independent assessment. Ask your compliance team to obtain the current versions and to record which version they relied on. If a web page and a governing document ever appear to conflict, treat the governing document as authoritative and raise the question with Swift before you submit.
