SWIFT CSCF Mandatory vs Advisory Controls | Threat Manifest

Every bank preparing for a SWIFT CSP independent assessment eventually hits the same question: does it matter if a control is advisory?

The SWIFT mandatory controls in CSCF v2026 number 26, alongside 6 advisory controls. Which bucket a control sits in determines whether a gap blocks your attestation or merely gets written up in your report — and banks that conflate the two are the banks that discover the difference during fieldwork.

The official answer is straightforward — mandatory controls must be implemented, advisory controls are recommended best practice. That distinction is printed clearly in the CSCF documentation and repeated across every consultancy website that has ever written about the SWIFT CSP programme.

The practical answer is more complicated. And the gap between those two answers is exactly where banks get caught out.

This article explains what mandatory and advisory actually mean inside an assessment — not just what the labels say, but how an assessor documents them, how they appear in your IAF report, and why treating advisory controls as "not our problem yet" is one of the most reliable ways to create compliance failures in the next version cycle.

As of CSCF v2026, the framework contains 32 controls: 26 mandatory and 6 advisory.

What the CSCF Actually Contains — and Why the Split Matters

The Customer Security Controls Framework is organised around three objectives and seven security principles. Every control maps to one of those principles and carries one of two designations: mandatory or advisory.

Mandatory controls establish the security baseline that every SWIFT user must implement, regardless of their architecture type or size. They are non-negotiable for attestation purposes. If a mandatory control is not implemented, you cannot attest as compliant — full stop.

Advisory controls are controls that SWIFT considers best practice and recommends all users implement. They are not required for a passing attestation in the version where they carry the advisory designation. But that sentence contains two qualifications that matter: not required, and in the version where they carry the advisory designation.

The split also has an architecture dimension. Not every mandatory control applies to every architecture type. A bank on Architecture B has a significantly smaller mandatory control set than one on Architecture A1 or A2. This is why understanding your architecture type is the first step before any gap analysis — counting 26 mandatory controls means nothing until you know which of those 26 apply to your specific connectivity setup.

What the architecture table does not change is the status of advisory controls. Whether a control is advisory is a framework-level designation, not an architecture-level one.

What SWIFT Mandatory Controls Really Mean in an Assessment

In an independent assessment, mandatory controls are assessed as a binary: implemented or not implemented. The assessor reviews your evidence against each applicable mandatory control, tests the implementation where testing is required, and records a finding of compliant or non-compliant.

Non-compliant findings against mandatory controls are serious. They are recorded in the IAF assessment report, and they directly affect the attestation you submit to KYC-SA. A bank attesting as compliant while holding unresolved mandatory control failures is submitting an inaccurate attestation — which SWIFT treats as a compliance issue in itself.

What practitioners who have run these assessments know — and what most written guidance glosses over — is that the evidence bar for mandatory controls is not uniform. Some mandatory controls have straightforward documentary evidence: a configuration screenshot, a policy document, an access control list. Others require the assessor to test live environments, review logging outputs, or validate that a process actually operates as documented rather than just existing on paper.

The mandatory label tells you a control is required — it does not tell you how hard it will be to demonstrate. A control can be mandatory and straightforward. Another can be mandatory and the hardest thing you test all engagement.

This is covered in detail in the independent assessment process, but the relevant point here is that the mandatory label tells you a control is required — it does not tell you how hard it will be to demonstrate. A control like 4.1 (Password Policy) is relatively simple to evidence. A control like 2.9 (Transaction Business Controls) involves operational testing that many banks underestimate until they are sitting in the assessment.

What "Advisory" Really Means — and Why It Still Shows Up in Findings

Here is the part that most online content does not address.

Advisory controls are optional for attestation purposes. But advisory controls are not optional for documentation purposes in an IAF assessment.

The Independent Assessment Framework includes supporting templates that cover both mandatory and advisory controls. A Community Standard Assessment — the baseline assessment type required for all SWIFT users — covers mandatory controls as a minimum. But assessors document advisory control status in their findings regardless of whether the bank has implemented them.

This means your IAF report will contain a section on advisory controls. If you have gaps against advisory controls, those gaps are written up. The report goes to your bank's management. In many jurisdictions, regulatory bodies that oversee SWIFT users have access to or request sight of these reports.

The practical consequence is this: a bank that has chosen not to implement any advisory controls will have six documented gaps in its assessment report, even though none of those gaps prevent a compliant attestation in v2026. Whether those documented gaps are acceptable to your board, your regulator, or your counterparties is a separate question — and it is a question the mandatory/advisory label does not answer for you.

There is also a scoping decision that every bank and assessor faces at the start of an engagement: do you include advisory controls in the formal scope of the assessment, or assess mandatory controls only? This is a real conversation with real consequences. Including advisory controls gives you a fuller picture of your security posture and a cleaner report. Excluding them saves assessment time but leaves gaps undocumented until you choose to address them. Neither choice is wrong — but it should be a deliberate decision, not a default.

How the Mandatory/Advisory Split Has Shifted Across CSCF Versions

The most important thing to understand about the advisory designation is that it is temporary by design.

SWIFT's change management policy is explicit on this point: all new mandatory controls are first introduced as advisory, giving banks at least two version cycles — roughly 18 months to two years — to plan, budget, and implement before the control becomes a compliance requirement.

This means the advisory control list in any given CSCF version is not a list of things that will never be mandatory. It is a list of things that are not yet mandatory. The distinction matters enormously for planning.

The migration pattern is consistent across every CSCF version since the framework launched. Controls that appear as advisory in one cycle routinely appear as mandatory one or two cycles later. A bank that waits until a control becomes mandatory to begin implementation typically finds itself in a reactive remediation posture — scrambling to meet a requirement that has been visible on the horizon for two years.

The most recent and cleanest example of this pattern is Control 2.4 (Back Office Data Flow Security). This control appeared as advisory in CSCF v2025. Banks preparing for their v2025 attestation could legitimately treat it as optional. In CSCF v2026, Control 2.4 carries no advisory designation — it is a mandatory control. Banks that treated the advisory period as a grace period are now non-compliant against a control they had 18 months of warning on.

Control 1.4 (Restriction of Internet Access) followed the same path in an earlier cycle — advisory, then mandatory. The pattern repeats.

Which Controls Are Advisory in v2026 — and What That Signals

Based on CSCF v2026, the six advisory controls are:

2.5A — External Transmission Data Protection Focused on protecting data transmitted externally from the SWIFT environment. The "A" designation means it is not required for attestation in v2026. Given the direction of travel in the framework — increasing focus on data flows beyond the immediate SWIFT zone — this is a candidate for promotion in a future cycle.

2.11A — RMA Business Controls Relates to Relationship Management Application controls — managing which counterparties your institution maintains active RMA relationships with, and applying business logic to those relationships. Operationally relevant for any bank with a large correspondent banking network.

5.3A — Staff Screening Process Covers background screening of staff with access to SWIFT-related infrastructure. It is advisory in v2026 but sits in the same objective cluster as mandatory identity and access management controls. Banks with mature HR security programmes typically already have this in place; banks without it have a gap that is increasingly visible in assessments.

6.5A — Intrusion Detection Given that Objective 6 is "Detect Anomalous Activity to Systems or Transaction Records," having an intrusion detection capability marked advisory feels incongruous — and that tension is worth noting. Banks relying purely on mandatory controls in this objective have a thinner detection capability than the framework's own intent suggests.

7.3A — Penetration Testing Periodic penetration testing of SWIFT-related infrastructure is advisory in v2026. For any bank that has implemented a mature security programme, this is already happening. For banks that have not yet formalised penetration testing, the advisory designation should not be read as SWIFT's endorsement of skipping it.

7.4A — Scenario-based Risk Assessment Tabletop exercises and scenario-based testing of your incident response capability. Advisory in v2026, but tied directly to 7.1 (Cyber Incident Response Planning), which is mandatory. Having a plan without testing it is a gap that assessors notice even when they cannot formally rate it as non-compliant.

How to Use This Distinction When Preparing for Your Assessment

The advisory control list in any given CSCF version is not a list of things that will never be mandatory. It is a list of things that are not yet mandatory. The distinction matters enormously for planning.

The practical framework for any bank approaching a SWIFT CSP assessment is this:

Treat mandatory controls as your compliance floor, not your ceiling. Every applicable mandatory control must be implemented and evidenced. There is no discretion here, and there is no benefit in treating the mandatory list as the complete picture of what your SWIFT environment should look like.

Treat advisory controls as your forward planning list. Review which advisory controls are relevant to your architecture type and existing security programme. For each one, ask: how much effort would implementation require, and what is the probability this becomes mandatory in the next one or two cycles? The answer to that question — not whether it is advisory today — should drive your prioritisation.

Have the scoping conversation with your assessor early. Before fieldwork begins, decide whether advisory controls are in scope for your assessment. If you have implemented most of them, including them costs little and produces a cleaner report. If you have significant gaps, you may prefer to scope them out of the formal assessment — but document that decision, and build a remediation timeline before your next cycle.

Use the advisory period as implementation runway, not permission to defer. The 18-month change management window exists to give banks time to implement, not time to wait. Control 2.4 is the most recent example of what happens when banks treat advisory as permanent rather than transitional.

For a full reference of all 32 CSCF v2026 controls — with per-control applicability by architecture type — see the SWIFT CSP control reference.