Which SWIFT CSCF controls are mandatory and which are advisory in v2026?
CSCF v2026 has 32 controls, 26 mandatory and 6 advisory, and your attestation must cover at least the mandatory controls in force on the date you attest. The advisory controls may also be attested, but they do not replace any mandatory control. If you are preparing your KYC-Security Attestation between July and December 2026, the control list is the place to start your gap analysis, and the 26 mandatory controls are the baseline you cannot skip.
The list is not the answer on its own. Which controls apply depends on your architecture type and on the components you own in your own environment. Swift's guidance states that controls for A1, A2 and A3 are identical, with fewer applying to A4 and fewer again to B, so two Swift users can face very different scopes under the same version. Customer client connectors are in scope for 14 controls in v2026, so check early whether your connector sits inside your own infrastructure or with a service provider. Confirm your architecture type and component ownership with your Swift administrator and your internal assessor before you build the control inventory, since a wrong scope decision is expensive to correct late in the cycle. The Swift Customer Security Controls Framework v2026 requires a Swift login, and it is the authoritative source for the scope rules.
The six advisory controls in CSCF v2026
This table lists the six CSCF v2026 controls that carry advisory status, with the objective and principle each sits under. Advisory controls are recommended good practice and do not set the attestation baseline, so each row ends with what to confirm before deciding whether to implement it voluntarily.
| Control | Objective and principle | What to confirm first |
|---|---|---|
| 2.5A External Transmission Data Protection | Secure your environment, reduce attack surface and vulnerabilities | Which Swift-related data leaves your environment, who receives it, and how it is protected in transit today. |
| 2.11A RMA Business Controls | Secure your environment, reduce attack surface and vulnerabilities | Who can change RMA relationships and whether business-level checks already exist alongside the technical controls. |
| 5.3A Staff Screening Process | Know and limit access, manage identities and segregate privileges | Whether your screening process covers staff holding Swift privileges and whether local law allows it for those roles. |
| 6.5A Intrusion Detection | Detect and respond, detect anomalous activity | Whether detection covers the Swift infrastructure in your architecture and who reviews and acts on its alerts. |
| 7.3A Penetration Testing | Detect and respond, plan for incident response and information sharing | Whether existing tests include Swift components, how often they run, and who receives and acts on the findings. |
| 7.4A Scenario-based Risk Assessment | Detect and respond, plan for incident response and information sharing | Whether current risk scenarios include compromise of Swift access and how the results feed incident planning. |
What changed in CSCF v2026
CSCF v2026 changes the scope of the framework in ways that affect which controls you implement and which evidence you hand to your assessor. The four changes below cover one control moving to mandatory, a connector change that touches fourteen controls, the publication and attestation dates, and the architecture-dependent effect of that connector change. Read them together with the full v2026 document, since each change interacts with your architecture type.
Control 2.4 becomes mandatory
Control 2.4 Back Office Data Flow Security is now mandatory in CSCF v2026. Swift announced this change the previous year, so users had a preparation window before it applied. The control concerns how data flows between your back-office systems and the Swift-related infrastructure. If you treated it as optional guidance, your attestation will not reflect compliance with the mandatory baseline. Map the data flows in your back office, confirm each one is protected as the control requires, and keep records your assessor can test.
Connectors join 14 controls
Customer client connectors are now in-scope components of 14 controls: 1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1 and 6.4. A connector that was previously treated as peripheral may now need the same hardening, access and monitoring evidence as the core Swift components. Start by inventorying every connector in your estate, including those run by a service bureau, and record which of the 14 controls each one falls under.
Connector scope depends on architecture
The effect of the connector change depends on your architecture type. Which controls apply is set by whether you run A1, A2, A3, A4 or B, and fewer controls apply to A4 and fewer again to B. A user on a type with a smaller control set may find that connectors bring in fewer of the 14 controls than an A1 user would see. Confirm your architecture type first, then work out which connector-related controls remain in scope before you scope any remediation work.
Published July 2025, attested 2026
CSCF v2026 was published in July 2025 and is the version you attest against from July to December 2026. Swift publishes each version a year before it applies, so the published date is the point when your preparation should already be under way. Confirm the attestation window and submission steps in the KYC-SA application each year, because the dates are set by Swift and not by your internal project plan.
How a control moves from advisory to mandatory
The sequence gives you a dated trail from the first announcement of a new control to the attestation that proves you meet it, so nothing reaches mandatory status without your team having planned for it. It turns a Swift publication into owned tasks, evidence and a sign-off you can show your supervisors.
Watch for the annual CSCF release
Swift publishes a new CSCF version every July, and that version applies a year later. Your compliance lead or CSP owner reviews the new control list, marks every control that is new, changed or moved, and records the publication in your CSP register. The step is done when the register shows the new version, its date and an owner for the review.
Log new controls and components as advisory
New controls or components usually enter as advisory, which means they are recommended good practice and not yet part of the mandatory baseline. Log each advisory item as its own entry with its control ID, the architecture types it touches and the systems it would affect. Advisory status does not remove the item from your planning, so the entry stays open until it is assessed. The output is a logged item for every advisory control in the new version.
Assess gaps against your current environment
Map each logged item to your Swift-related infrastructure and compare what you have with what the control objective asks for. Include customer connectors where they are in scope, since the current version made them mandatory components of 14 controls. Assign a named owner to each gap and a target for closure in your own plan. The step closes when every logged item has a gap rating and an owner.
Plan changes within the preparation window
Swift's change management gives users up to 18 months to prepare for new or changed controls, so you schedule remediation against that window rather than against the July publication. Record each change as a task with an owner, a dependency list and an evidence requirement, such as a configuration export, a policy or a test record. Confirm with your assessor which items they expect to see. The output is a remediation plan with evidence defined for each task.
Implement and collect evidence
Deliver the changes and keep the evidence that shows each control is working, not only that a change was made. Store the evidence against the control ID in your assessment file so the independent assessor can trace it without rebuilding the story. Where you use an alternative solution, record how it meets the control objective and the risks it addresses. The step is done when each task has its evidence filed and reviewed.
Track the status change to mandatory
Advisory controls can become mandatory in a later CSCF version, and the change must be reflected in the attestation for that cycle. Keep the status of each control in your register and update it when Swift publishes the version that makes it mandatory. Confirm the status against Swift's published control list rather than an internal assumption. The output is a register that shows each control's current status and the version that set it.
Attest against the mandatory controls
Your attestation in the KYC-SA application must reflect compliance against at least the mandatory controls in force, and it may also cover advisory controls. Before submission, your assessor's report and your evidence file should match the status recorded in your register for each control. Ask your assessor to confirm this match in writing. The step closes when the attestation is submitted with a traceable link from each mandatory control to its evidence.
How architecture type changes which controls apply
Users with architecture types A1, A2 and A3 face the same control set in CSCF v2026. The distinction between these three types lies in how the Swift-related infrastructure is built and operated, not in which controls apply. For that reason, a user who moves between A1, A2 and A3 as its connectivity changes should not expect its control list to shrink or grow simply because the architecture label changed. The controls still have to be implemented and evidenced against the infrastructure that actually exists.
- Identical control list: A1, A2 and A3 carry the same set of controls, so the full mandatory baseline applies.
- Infrastructure still decides evidence: Each type places components in different locations, so the same control may be evidenced from different systems.
- Client connectors are in scope: Customer client connectors are mandatory in-scope components of 14 controls, including 1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1 and 6.4.
- Advisory controls remain optional: The six advisory controls can still be attested, but they are not required for compliance.
Confirm your type with the architecture types sibling topic before you scope the gap analysis, because the label drives the whole control list.
Architecture type A4 has fewer controls in scope than A1, A2 and A3. The reduction follows from the components the user owns and operates, so the user must confirm which Swift-related components sit in its environment before assuming any control falls away. Fewer controls do not mean fewer obligations on the components that remain, and a control removed from scope for A4 may still matter for other systems the organization runs.
- Reduced list: A4 applies fewer controls than the A1 to A3 set, and the exact list is published by Swift for the version in force.
- Ownership drives the change: The reduction depends on component and licence ownership, not on company size or sector.
- Remaining controls stay strict: Controls that still apply must be implemented with the same rigour as in the broader set.
- Shared infrastructure needs review: If a component serves both Swift and non-Swift workloads, check whether a removed control still covers that shared asset.
- Documented rationale: Record why each control is out of scope so that an assessor can trace the decision.
Before relying on the A4 list, check the control applicability table in the current CSCF v2026 document, since that is the authoritative source.
Architecture type B has the smallest set of controls in scope. Because fewer controls apply, a B user's attestation is narrower, but its obligations are still defined by the components it runs and the connectivity it uses. Many B users discover that the smaller list still requires significant evidence for the controls that do apply, particularly around access, credentials and the client connector.
- Smallest applicable set: B carries fewer controls than A4, A1, A2 and A3.
- Connector obligations persist: Where the customer client connector is a component in scope, the related controls still apply.
- Scope boundary must be proven: Show the assessor where the Swift environment starts and stops, since the boundary determines which controls are in play.
- Service provider dependencies: Where a third party operates part of the chain, document what that party provides and what the user still must evidence.
- Re-check after changes: A change in ownership or connectivity can move a user to a different type and change the control list.
Confirm the B list against the official CSCF v2026 document and your own component inventory before you commit to a scope.
The figure of 26 mandatory controls is the full v2026 set, drawn from the complete framework. It is not the number of controls that every Swift user must implement. Applicability depends on architecture type, so a user may face fewer mandatory controls in practice. Treating 26 as a universal checklist can lead to over-scoping, while assuming a smaller number without checking can lead to an incomplete attestation.
- Full catalogue: The 26 mandatory and 6 advisory controls together make up the 32 controls of CSCF v2026.
- Applicability filter: The architecture type removes or keeps controls before any mandatory status is applied.
- Advisory is separate: The six advisory controls are not part of the mandatory baseline for any architecture type.
- Version matters: Counts and applicability are tied to a specific CSCF version, so do not reuse a list from an earlier version.
- Written scope: Record the applicable list in the gap analysis so the attestation maps to a documented set.
Ask your assessor or implementation partner to produce the applicable control list for your architecture type before any evidence collection starts.
Can you use an alternative to Swift's implementation guidance?
Yes. Swift lets users follow its implementation guidance for each control or use an alternative solution, provided the alternative meets the control objective and addresses the risks the control is meant to cover. The test is outcome-based, so a different tool or configuration is acceptable if you can show it achieves the same protection. The decision is yours, and it applies to each mandatory control you choose to implement differently, including the 26 mandatory controls in CSCF v2026. Read the control's objective and its documented risks in the Swift CSP controls guidance before deciding, because the objective is what you must prove, not the method.
For an alternative, the independent assessor will expect a written rationale that names the control, the objective, the risk it addresses and the specific design you chose. Expect to show how the alternative operates in your Swift-related environment, not in a general sense: the systems in scope, the configuration or process in place, who runs it, and how you know it works. Evidence typically includes configuration exports, logs or reports that demonstrate the protection is active, test results, and records showing the control has operated over time. Confirm with your assessor early which evidence they need, because an alternative that looks sound on paper can still fail if the operating evidence is thin.
Ownership of the decision and its documentation stays with your organization, and so does accountability for the attestation you submit. An implementation partner can help map the alternative to the control objective, draft the rationale, and gather the evidence, which often reduces rework. However, the partner cannot approve the design, and the assessor alone decides whether the evidence is sufficient. Ask your assessor to review the rationale before you invest in building the alternative, since a reviewed design avoids the cost of retrofitting evidence after the assessment starts.
What happens if a mandatory control is not met
A mandatory control gap is not a paperwork issue. It affects how Swift and your supervisors see your attestation, and it can leave a control unproven at the moment you need to show compliance. The four cards below cover the consequences that follow most often and the action a compliance lead should take to prevent each one.
Missing or non-compliant attestation
Swift may report users who have no valid attestation or who are not compliant with the mandatory controls. Your attestation is the single record Swift uses to judge your status, so a gap in it is a gap in your standing with Swift. Before the July to December window opens, confirm that someone with authority will sign the attestation, that the mandatory controls in force are listed, and that each one has an owner and current evidence. Treat the attestation as a deliverable with a named owner, not a yearly form.
Gaps visible to supervisors
Swift can make the lack of compliance visible to the users' supervisors, so a mandatory control gap can reach people outside your IT and security teams. Supervisors may ask why a gap exists, what it puts at risk and when it will close. Prepare a short internal summary of each open mandatory gap, with the control ID, the remediation owner and the target date, so that the answer is ready before anyone asks. Escalate gaps to your supervisor before Swift does.
Advisory-only attestation falls short
Attesting only against advisory controls does not satisfy the mandatory baseline. Advisory controls such as 6.5A Intrusion Detection are recommended practice, and they can be attested in addition to the mandatory set. Teams sometimes show strong results on the six advisory controls and assume the attestation is complete. Before submitting, map every one of the 26 mandatory controls to evidence, and confirm that advisory results are reported alongside, not instead of, the mandatory set.
Late-mandatory controls create gaps
Control 2.4 Back Office Data Flow Security became mandatory in CSCF v2026, and the client connectors of 14 controls became in-scope components. A control that was advisory last year can become mandatory at attestation time, and a component you did not consider in scope can bring a control with it. Review the v2026 changes against your last attestation, and confirm the status of each control, including client connectors, before you start the gap analysis. Check the status of every control against the version in force, not the version you attested last year.
Frequently asked questions about CSCF mandatory and advisory controls
How many CSCF v2026 controls are mandatory?
CSCF v2026 contains 32 controls, of which 26 are mandatory and 6 are advisory. The mandatory set is the security baseline every Swift user must implement on its Swift-related infrastructure, so it is the number that drives most of the implementation and assessment work. The count alone does not show the effort, because the controls in scope depend on your architecture type. Controls for A1, A2 and A3 are identical, fewer apply to A4, and fewer again apply to B. Check the control list against your own architecture before you size the work. The official v2026 document, available behind a Swift login, sets out the definitive list and is the document to cite in your attestation file.
Do advisory controls have to be attested?
No. Advisory controls are recommended good practice, and the attestation must reflect compliance against at least the mandatory controls in force. You may also attest to advisory controls, and some organizations do so to show a higher level of maturity to counterparties. Be aware that the six advisory controls in v2026 are 2.5A External Transmission Data Protection, 2.11A RMA Business Controls, 5.3A Staff Screening Process, 6.5A Intrusion Detection, 7.3A Penetration Testing and 7.4A Scenario-based Risk Assessment. Advisory status is not permanent. New controls and components are introduced as advisory first, so an advisory control today may become mandatory in a later version. Plan for that transition when you design your controls roadmap.
Can a mandatory control be skipped if it does not fit our environment?
Not on the basis of fit alone. Each mandatory control applies to in-scope components, so the first step is to confirm with your architecture type whether the control is in scope at all. Where a control applies, you may follow Swift's implementation guidance or use an alternative solution, provided it meets the control objective and addresses the documented risks. That means a documented justification, not an omission. Record the reasoning, the compensating measures and the residual risk, and have the independent assessor test that reasoning. Swift can report users who are not compliant with mandatory controls, and that status is visible to their supervisors, so an undocumented exception is a serious exposure.
How much effort does it take to implement and assess the mandatory controls?
No effort figure has been published for this page, and any number you see from a third party should be checked against your own scope. The effort depends on how many components you run, how many connect through customer client connectors, how mature your current security controls are, and how much evidence already exists. Connectors are in scope for 14 controls in v2026, so an environment with more connectors usually carries more work. Ask any implementation partner or assessor for a written scope that lists the architecture type, the in-scope components, the controls to be implemented, the evidence to be produced and the assessment steps. A quote should follow from that scope. Ask whether the figure covers one-time implementation, the recurring annual assessment, and any retesting or evidence refresh.
Can we implement and assess the CSCF controls ourselves?
Often yes, but the answer depends on your internal capacity and independence rules. Swift allows the independent assessment to be internal, carried out by a second or third line function such as risk, compliance or internal audit, or external. Swift's CSP Assessor Certification is optional, so it is not a precondition for an internal team. The organization owns its controls and its attestation in every case. An implementation partner such as DeployOpen can prepare systems, configure hardening, and assemble evidence inside your own infrastructure, but it does not perform the independent assessment or issue any attestation. Decide early who will test the controls, because an assessor must be independent of the people who implemented them.
How do we confirm the current CSCF controls list?
Start with the official CSCF v2026 document, published by Swift in July 2025. It is available behind a Swift login at the Swift Knowledge Centre, and it is the authoritative source for the 32 controls, their mandatory or advisory status, and their applicability by architecture type. Cross-check it against Swift's CSP controls guidance, which explains how controls are defined and how changes are managed. Also check whether Swift has published a newer CSCF version, because it publishes a new version each July, ahead of the year it applies. Record the version number you assessed against in your attestation file, and confirm the list with your independent assessor before testing begins.
Which controls changed in v2026 and do they affect us?
Two changes matter most. Control 2.4 Back Office Data Flow Security became mandatory in CSCF v2026, as Swift had announced the previous year. Customer client connectors also became mandatory in-scope components of 14 controls: 1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1 and 6.4. If you run connectors, these changes extend the scope of existing controls even where the control itself looks familiar. Compare your current control evidence against the v2026 wording for each affected control. Swift's change management gives users up to 18 months to prepare for new or changed controls, but you should confirm the exact timing for your attestation window with Swift.
How DeployOpen works on this
DeployOpen works on the Swift infrastructure your organization operates, in your own cloud accounts, data centers or air-gapped networks. We prepare the systems and evidence behind each mandatory and advisory control, while your organization keeps ownership of its controls and attestation, and an independent assessor tests them.
How we scope
- Confirm which CSCF v2026 controls apply to your architecture type and Swift-related components before work starts.
- Record in writing which mandatory controls and any advisory controls are in the engagement, with deliverables and timelines.
- Agree with your assessor, in advance, the evidence format and the systems each control will be tested against.
How we build
- Harden and segregate the in-scope Swift environment, including connectors, back office data flows and access paths.
- Configure access, credential, identity and logging controls on the platforms you run, documenting each design decision.
- Test the implemented controls against the documented control objectives, and record gaps for your remediation plan.
How we hand over
- Deliver control documentation mapped to each in-scope CSCF v2026 control ID, with the configuration and test records behind it.
- Provide evidence packs that your internal or external assessor can sample, reproduce and examine without DeployOpen present.
- Confirm with you what remains your responsibility, including the attestation submitted in the KYC-SA application.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Plan for the next CSCF version in advance, since Swift publishes each version a year before it applies.
- Ask us to re-check evidence when a control moves from advisory to mandatory or when your architecture changes.
