Kilde › Guides › SWIFT CSP › CSCF v2026, control by control: the ev…
Current to 26 August 2026 · updates land in the changelog.
CSCF v2026 carries 26 mandatory and 6 advisory controls, with 2.4 Back Office Data Flow Security promoted to mandatory this cycle and customer connectors newly in scope for 14 controls. Assessors report that controls fail on evidence far more often than on implementation. One section per control: the question it answers, the evidence that usually satisfies, the usual failure mode. Independent publication — not affiliated with, endorsed by or approved by S.W.I.F.T. SC; download the framework yourself and verify every line.
Control 1.1 — Swift Environment Protection is a mandatory control in CSCF v2026, sitting in Objective “Secure Your Environment”, Principle “Restrict Internet Access and Protect Critical Systems from General IT Environment”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
The boundary question: does a defined SWIFT secure zone actually exist, separated from your general IT estate — and can you show where its edge runs?
The artifact assessors reach for first is a current network diagram with the secure zone explicitly drawn — and the boundary enforcement that proves the drawing is real, not aspirational.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Diagrams that express intent while the actual rule base has accumulated years of exceptions nobody can justify in the meeting.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 1.1 in full before acting on any summary, this one included.
Yes. 1.1 Swift Environment Protection is one of the 26 mandatory controls in CSCF v2026.
The artifact assessors reach for first is a current network diagram with the secure zone explicitly drawn — and the boundary enforcement that proves the drawing is real, not aspirational. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 1.2 — Operating System Privileged Account Control under Objective “Secure Your Environment” (Principle: “Restrict Internet Access and Protect Critical Systems from General IT Environment”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The admin question: who holds operating-system-level power on in-scope machines, and is that power confined to the people and moments that need it?
A privileged-account inventory that someone recently reviewed — with the review itself on record, not just asserted.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Accounts everyone forgot: application service accounts with admin rights, and emergency access nobody inventoried.
Since v2026, customer connectors count as in-scope components here. A file-transfer client, a middleware feed or an API integration in your footprint owes this chapter evidence as well.
v2026 raises emphasis on Alliance LSO/RSO and break-glass accounts sitting inside privileged scope — name them in the inventory.
The authoritative text for control 1.2, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 1.2 Operating System Privileged Account Control among its 26 mandatory controls.
A privileged-account inventory that someone recently reviewed — with the review itself on record, not just asserted. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 1.3 — Virtualisation or Cloud Platform Protection is a mandatory control within Objective “Secure Your Environment”, Principle “Restrict Internet Access and Protect Critical Systems from General IT Environment”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The layer-below question: if in-scope systems run on a hypervisor or cloud platform, that platform is itself a place your SWIFT environment can be compromised from — is it treated with in-scope seriousness?
Documentation of the virtualisation layer's own hardening and access posture, at the same standard you'd apply to any in-scope host.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
A hardened guest on an unexamined host — the platform team and the SWIFT team each assuming the other owns it.
Scope note for v2026: this control reaches customer connectors. Where your footprint includes file-transfer clients, middleware or API integrations, gather their evidence under this heading too.
Nothing substitutes for the framework document. Control 1.3's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 1.3 Virtualisation or Cloud Platform Protection sits in the mandatory set (26 of the 32 v2026 controls).
Documentation of the virtualisation layer's own hardening and access posture, at the same standard you'd apply to any in-scope host. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 1.4 — Restriction of Internet Access is a mandatory control in CSCF v2026, sitting in Objective “Secure Your Environment”, Principle “Restrict Internet Access and Protect Critical Systems from General IT Environment”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
The egress question: can machines inside the secure zone reach the open internet — and if anything can, is every destination on a short, justified list?
Egress rules or proxy configuration exported from the enforcing device, alongside the allowed-destination list with a business reason per line.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Update servers, telemetry endpoints and admin conveniences that punched holes long ago and were never re-justified.
One v2026 scope fact to apply: customer connectors are in-scope components for this control. If a file-transfer client, middleware or an API integration is part of your footprint, its evidence belongs in this chapter too.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 1.4 in full before acting on any summary, this one included.
Yes. 1.4 Restriction of Internet Access is one of the 26 mandatory controls in CSCF v2026.
Egress rules or proxy configuration exported from the enforcing device, alongside the allowed-destination list with a business reason per line. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 1.5 — Customer Environment Protection under Objective “Secure Your Environment” (Principle: “Restrict Internet Access and Protect Critical Systems from General IT Environment”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
Applicability note: A4 architectures — the control that exists because customer connectors became first-class scope.
The A4 question: your connector environment is your SWIFT footprint — is it separated from the general enterprise network the way an interface zone would be?
The boundary drawn on a diagram plus the enforcing configuration — VLAN, firewall or host rules — exported with a date.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
File-transfer clients and middleware living on flat corporate networks because nobody classified them as SWIFT scope until the type changed to A4.
The authoritative text for control 1.5, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 1.5 Customer Environment Protection among its 26 mandatory controls.
The boundary drawn on a diagram plus the enforcing configuration — VLAN, firewall or host rules — exported with a date. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 2.1 — Internal Data Flow Security is a mandatory control within Objective “Secure Your Environment”, Principle “Reduce Attack Surface and Vulnerabilities”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The in-zone traffic question: are the hops between your own SWIFT-related components protected in transit, hop by hop?
The relevant slice of a flow inventory with the protection mechanism named per hop — and current crypto choices (the KB 5021566 baseline is the reference point assessors know).
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
Legacy internal hops on old protocol versions grandfathered in because they're 'inside the zone anyway'.
Nothing substitutes for the framework document. Control 2.1's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 2.1 Internal Data Flow Security sits in the mandatory set (26 of the 32 v2026 controls).
The relevant slice of a flow inventory with the protection mechanism named per hop — and current crypto choices (the KB 5021566 baseline is the reference point assessors know). As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 2.2 — Security Updates is a mandatory control in CSCF v2026, sitting in Objective “Secure Your Environment”, Principle “Reduce Attack Surface and Vulnerabilities”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
The patching question: do in-scope hosts and SWIFT-related software receive security updates on a defensible cadence, from vendors that still support them?
Patch records for the in-scope set plus a vendor-support status per component — the second half is the one that surfaces end-of-life surprises.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Connectors and middleware patched on the enterprise schedule (slowly) while the messaging interface gets the attention.
One v2026 scope fact to apply: customer connectors are in-scope components for this control. If a file-transfer client, middleware or an API integration is part of your footprint, its evidence belongs in this chapter too.
Customer connectors are squarely in-scope components for this control in v2026 — their patch trail counts.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 2.2 in full before acting on any summary, this one included.
Yes. 2.2 Security Updates is one of the 26 mandatory controls in CSCF v2026.
Patch records for the in-scope set plus a vendor-support status per component — the second half is the one that surfaces end-of-life surprises. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 2.3 — System Hardening under Objective “Secure Your Environment” (Principle: “Reduce Attack Surface and Vulnerabilities”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The baseline question: is there a named hardening standard for in-scope machines, and can you show the machines actually match it?
The baseline document plus a config-versus-baseline check per host class — the delta list is the evidence, not the baseline alone.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Administration and scripting channels left at defaults; v2026 names WMI and PowerShell, which is exactly where assessors now look first.
Since v2026, customer connectors count as in-scope components here. A file-transfer client, a middleware feed or an API integration in your footprint owes this chapter evidence as well.
v2026 explicitly calls out administration/scripting channels (WMI, PowerShell) as hardening territory.
The authoritative text for control 2.3, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 2.3 System Hardening among its 26 mandatory controls.
The baseline document plus a config-versus-baseline check per host class — the delta list is the evidence, not the baseline alone. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 2.4 — Back Office Data Flow Security is a mandatory control within Objective “Secure Your Environment”, Principle “Reduce Attack Surface and Vulnerabilities”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
Applicability note: The v2026 grid appears to mark 2.4 across architecture types while at least one assessor treats it as N/A for pure Type B — if you are B with genuinely nothing to protect, document the N/A rationale and verify against your own grid.
The corridor question — and 2026's headline: the newly mandatory control protecting the first hops between your back office and your SWIFT infrastructure against tampering and injection.
A complete flow inventory of that corridor — direct and indirect paths, bridging components included — with a protection pattern claimed per flow and written risk acceptances for the gaps. This is the control where 'we think we know our flows' goes to die.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
The inventory doesn't exist; bridging servers (MQ brokers, ESBs, file gateways) sit in ownership grey zones; legacy exceptions were agreed verbally years ago and never written down.
THE promotion: advisory to mandatory in v2026. New direct flows and bridging-server legs are in force now; legacy direct flows remain advisory until tentatively v2028 — tentative and announced, not in force.
Nothing substitutes for the framework document. Control 2.4's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 2.4 Back Office Data Flow Security sits in the mandatory set (26 of the 32 v2026 controls). It is the cycle's promotion: advisory in earlier versions, mandatory from v2026.
A complete flow inventory of that corridor — direct and indirect paths, bridging components included — with a protection pattern claimed per flow and written risk acceptances for the gaps. This is the control where 'we think we know our flows' goes to die. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 2.5A — External Transmission Data Protection is a advisory control in CSCF v2026, sitting in Objective “Secure Your Environment”, Principle “Reduce Attack Surface and Vulnerabilities”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
No attestation fails for skipping an advisory control. But the advisory set is where counterparties read maturity, so a practice you already run is worth evidencing in the same format as the mandatory ones.
The outbound question: when SWIFT-related data leaves your environment for external parties, is it protected in transmission?
Per-destination transmission protections listed and evidenced — an easy maturity chapter if you already run 2.1-style flow discipline.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Ad-hoc partner file exchanges set up outside the inventoried paths.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 2.5A in full before acting on any summary, this one included.
No. In v2026 it sits in the advisory set of six, which counterparties nonetheless read as a maturity signal.
Per-destination transmission protections listed and evidenced — an easy maturity chapter if you already run 2.1-style flow discipline. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 2.6 — Operator Session Confidentiality and Integrity under Objective “Secure Your Environment” (Principle: “Reduce Attack Surface and Vulnerabilities”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The human-session question: when operators and admins connect to in-scope systems, are those sessions encrypted, integrity-protected and time-bounded?
Session-protection configuration exported from the systems themselves, plus the timeout settings.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Jump-host paths and vendor remote-support sessions that bypass the protected route.
Since v2026, customer connectors count as in-scope components here. A file-transfer client, a middleware feed or an API integration in your footprint owes this chapter evidence as well.
The authoritative text for control 2.6, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 2.6 Operator Session Confidentiality and Integrity among its 26 mandatory controls.
Session-protection configuration exported from the systems themselves, plus the timeout settings. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 2.7 — Vulnerability Scanning is a mandatory control within Objective “Secure Your Environment”, Principle “Reduce Attack Surface and Vulnerabilities”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The findings question: does scanning actually cover every in-scope host, and does anyone demonstrably act on what it finds?
The scan scope list reconciled against the components register, the latest report, and the triage trail for its findings — coverage plus follow-through.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
Scope lists that quietly exclude the connector, and criticals that age in a ticket queue.
Scope note for v2026: this control reaches customer connectors. Where your footprint includes file-transfer clients, middleware or API integrations, gather their evidence under this heading too.
Nothing substitutes for the framework document. Control 2.7's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 2.7 Vulnerability Scanning sits in the mandatory set (26 of the 32 v2026 controls).
The scan scope list reconciled against the components register, the latest report, and the triage trail for its findings — coverage plus follow-through. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 2.8 — Outsourced Critical Activity Protection is a mandatory control in CSCF v2026, sitting in Objective “Secure Your Environment”, Principle “Reduce Attack Surface and Vulnerabilities”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
The provider question: which critical SWIFT-related activities did you hand to third parties, and what assurance do you actually hold about how they run them?
A provider register naming each outsourced activity with the contract or assurance covering it — and, for service-bureau users, the provider's compliance results on file (their programme status is auto-appended to your published attestation).
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Accountability assumed to transfer with the outsourcing contract. It doesn't — responsibility stays with the individual SWIFT user regardless of architecture.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 2.8 in full before acting on any summary, this one included.
Yes. 2.8 Outsourced Critical Activity Protection is one of the 26 mandatory controls in CSCF v2026.
A provider register naming each outsourced activity with the contract or assurance covering it — and, for service-bureau users, the provider's compliance results on file (their programme status is auto-appended to your published attestation). Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 2.9 — Transaction Business Controls under Objective “Secure Your Environment” (Principle: “Reduce Attack Surface and Vulnerabilities”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The fraud-lens question: if anomalous outbound traffic started tonight — wrong hours, wrong counterparty, wrong size — what would detect or stop it, and how fast?
The business-control set described with its evidence: limits, out-of-hours handling, reconciliation and approval separation, with a worked example of an anomaly surfacing.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Controls that exist in the payments team's habits but nowhere on paper — invisible to an assessor.
v2026 accepts Swift Universal Confirmations as one validation alternative — if you run it, say so in the evidence.
The authoritative text for control 2.9, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 2.9 Transaction Business Controls among its 26 mandatory controls.
The business-control set described with its evidence: limits, out-of-hours handling, reconciliation and approval separation, with a worked example of an anomaly surfacing. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 2.10 — Application Hardening is a mandatory control within Objective “Secure Your Environment”, Principle “Reduce Attack Surface and Vulnerabilities”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The application-layer question: are SWIFT-related applications configured to their vendor's security guidance, with unused surface switched off?
The vendor security-configuration guidance you follow, deltas documented, and integrity verification of installed software feeding the 6.2 story.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
Default installs that work perfectly — which is why nobody ever revisited their configuration.
Nothing substitutes for the framework document. Control 2.10's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 2.10 Application Hardening sits in the mandatory set (26 of the 32 v2026 controls).
The vendor security-configuration guidance you follow, deltas documented, and integrity verification of installed software feeding the 6.2 story. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 2.11A — RMA Business Controls is a advisory control in CSCF v2026, sitting in Objective “Secure Your Environment”, Principle “Reduce Attack Surface and Vulnerabilities”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
No attestation fails for skipping an advisory control. But the advisory set is where counterparties read maturity, so a practice you already run is worth evidencing in the same format as the mandatory ones.
The relationship question: are your RMA relationships curated — dormant counterparty authorisations reviewed and pruned rather than accumulating forever?
A dated RMA review with decisions attached — kept relationships justified, dead ones closed.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Years of accumulated authorisations nobody owns, widening who could send you traffic.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 2.11A in full before acting on any summary, this one included.
No. In v2026 it sits in the advisory set of six, which counterparties nonetheless read as a maturity signal.
A dated RMA review with decisions attached — kept relationships justified, dead ones closed. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 3.1 — Physical Security under Objective “Secure Your Environment” (Principle: “Physically Secure the Environment”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The where-does-it-live question: are the physical spaces holding in-scope kit — servers, connectors, operator PCs per your type — actually access-controlled?
The access-control method per location plus entry records or a key register; for browser-only setups the operator-PC environment is the footprint that needs the answer.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Home-office operator PCs with no stated position — silence where a documented stance (either way) would pass.
Since v2026, customer connectors count as in-scope components here. A file-transfer client, a middleware feed or an API integration in your footprint owes this chapter evidence as well.
The authoritative text for control 3.1, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 3.1 Physical Security among its 26 mandatory controls.
The access-control method per location plus entry records or a key register; for browser-only setups the operator-PC environment is the footprint that needs the answer. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 4.1 — Password Policy is a mandatory control within Objective “Know and Limit Access”, Principle “Prevent Compromise of Credentials”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The policy-vs-reality question: does the written password standard demonstrably govern the in-scope systems — including the accounts nobody logs in with?
The standard next to a configuration export from in-scope systems proving enforcement there — plus a spot-check on local and service accounts.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
A beautiful corporate policy enforced everywhere except the SWIFT-adjacent boxes with local accounts.
Scope note for v2026: this control reaches customer connectors. Where your footprint includes file-transfer clients, middleware or API integrations, gather their evidence under this heading too.
Nothing substitutes for the framework document. Control 4.1's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 4.1 Password Policy sits in the mandatory set (26 of the 32 v2026 controls).
The standard next to a configuration export from in-scope systems proving enforcement there — plus a spot-check on local and service accounts. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 4.2 — Multi-Factor Authentication is a mandatory control in CSCF v2026, sitting in Objective “Know and Limit Access”, Principle “Prevent Compromise of Credentials”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
The second-factor question: is every interactive path into in-scope systems behind MFA — with no forgotten side doors?
An inventory of interactive access paths with the MFA mechanism named per path — the inventory is what turns 'we have MFA' into evidence.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
The forgotten paths: local console access, vendor support routes, and infrastructure admin interfaces.
One v2026 scope fact to apply: customer connectors are in-scope components for this control. If a file-transfer client, middleware or an API integration is part of your footprint, its evidence belongs in this chapter too.
v2026 tightens remote/external privileged access — firewall administrators explicitly included behind MFA.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 4.2 in full before acting on any summary, this one included.
Yes. 4.2 Multi-Factor Authentication is one of the 26 mandatory controls in CSCF v2026.
An inventory of interactive access paths with the MFA mechanism named per path — the inventory is what turns 'we have MFA' into evidence. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 5.1 — Logical Access Control under Objective “Know and Limit Access” (Principle: “Manage Identities and Separate Privileges”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The who-can-do-what question: is SWIFT-scope access granted on need-to-know, recertified on a cycle, and separated so no one person can both create and approve?
Joiner-mover-leaver records for the scope plus the latest access recertification with its outcomes.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Leavers and movers whose access outlived their role — the first thing a recertification surfaces and the first thing its absence hides.
Since v2026, customer connectors count as in-scope components here. A file-transfer client, a middleware feed or an API integration in your footprint owes this chapter evidence as well.
The authoritative text for control 5.1, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 5.1 Logical Access Control among its 26 mandatory controls.
Joiner-mover-leaver records for the scope plus the latest access recertification with its outcomes. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 5.2 — Token Management is a mandatory control within Objective “Know and Limit Access”, Principle “Manage Identities and Separate Privileges”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The credential-object question: where are the tokens, certificates and HSM-held credentials, who has custody, and what happened to the revoked ones?
A register covering issuance, custody, storage location and revocation events — lifecycle, not just existence.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
Certificates that outlived the people and servers they were issued for.
Nothing substitutes for the framework document. Control 5.2's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 5.2 Token Management sits in the mandatory set (26 of the 32 v2026 controls).
A register covering issuance, custody, storage location and revocation events — lifecycle, not just existence. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 5.3A — Staff Screening Process is a advisory control in CSCF v2026, sitting in Objective “Know and Limit Access”, Principle “Manage Identities and Separate Privileges”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
No attestation fails for skipping an advisory control. But the advisory set is where counterparties read maturity, so a practice you already run is worth evidencing in the same format as the mandatory ones.
The people question: are staff in sensitive SWIFT-scope roles screened at hire and on role change?
The screening step documented in the hiring/role-change flow for scope roles — usually HR already does it; the gap is connecting it to the SWIFT role list.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Screening that exists company-wide but was never mapped to who actually holds scope access.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 5.3A in full before acting on any summary, this one included.
No. In v2026 it sits in the advisory set of six, which counterparties nonetheless read as a maturity signal.
The screening step documented in the hiring/role-change flow for scope roles — usually HR already does it; the gap is connecting it to the SWIFT role list. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 5.4 — Password Repository Protection under Objective “Know and Limit Access” (Principle: “Manage Identities and Separate Privileges”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The keys-to-the-keys question: wherever privileged and application passwords live — vault, KeePass file, sealed envelope — is that store itself defended and its access short-listed?
The store named, its own protection configuration, the access list to it, and the rotation/break-glass procedure.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
A hardened vault with a shared master credential half the team knows.
Since v2026, customer connectors count as in-scope components here. A file-transfer client, a middleware feed or an API integration in your footprint owes this chapter evidence as well.
The authoritative text for control 5.4, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 5.4 Password Repository Protection among its 26 mandatory controls.
The store named, its own protection configuration, the access list to it, and the rotation/break-glass procedure. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 6.1 — Malware Protection is a mandatory control within Objective “Detect and Respond”, Principle “Detect Anomalous Activity to Systems or Transaction Records”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The coverage question: does anti-malware protection — or a reasoned equivalent — cover every in-scope host, with updates flowing and alerts landing somewhere staffed?
A coverage list reconciling every in-scope host to its anti-malware state, with update and alert evidence.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
Non-Windows systems in the secure zone assumed exempt by platform folklore rather than documented reasoning.
Scope note for v2026: this control reaches customer connectors. Where your footprint includes file-transfer clients, middleware or API integrations, gather their evidence under this heading too.
v2026 extends the expectation to non-Windows secure-zone systems — mechanism or reasoned position, documented either way.
Nothing substitutes for the framework document. Control 6.1's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 6.1 Malware Protection sits in the mandatory set (26 of the 32 v2026 controls).
A coverage list reconciling every in-scope host to its anti-malware state, with update and alert evidence. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 6.2 — Software Integrity is a mandatory control in CSCF v2026, sitting in Objective “Detect and Respond”, Principle “Detect Anomalous Activity to Systems or Transaction Records”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
The supply-chain question: do you verify that what you install and run is what the vendor shipped — and would you notice if it changed?
Checksum/signature verification records for installs and updates, plus integrity-monitoring output where it runs.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Downloads installed on trust for years — the habit v2026's checksum emphasis exists to end.
v2026 sharpens software-integrity/checksum expectations across SWIFT-related software.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 6.2 in full before acting on any summary, this one included.
Yes. 6.2 Software Integrity is one of the 26 mandatory controls in CSCF v2026.
Checksum/signature verification records for installs and updates, plus integrity-monitoring output where it runs. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 6.3 — Database Integrity under Objective “Detect and Respond” (Principle: “Detect Anomalous Activity to Systems or Transaction Records”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The records question: for databases behind in-scope applications — who and what can write, and would tampering surface?
The write-access map plus vendor-recommended integrity features shown enabled, with the logs or checks that would catch alteration.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Direct DBA write paths around the application, invisible to application-level controls.
The authoritative text for control 6.3, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 6.3 Database Integrity among its 26 mandatory controls.
The write-access map plus vendor-recommended integrity features shown enabled, with the logs or checks that would catch alteration. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 6.4 — Logging and Monitoring is a mandatory control within Objective “Detect and Respond”, Principle “Detect Anomalous Activity to Systems or Transaction Records”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The would-anyone-notice question: what do in-scope systems log, where does it go, how long does it live — and who or what actually reacts?
Per-host logging coverage with destination and retention — and the part assessors probe: one worked example of an alert handled end to end.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
Logs that flow to a platform nobody watches; collection mistaken for monitoring.
Scope note for v2026: this control reaches customer connectors. Where your footprint includes file-transfer clients, middleware or API integrations, gather their evidence under this heading too.
Nothing substitutes for the framework document. Control 6.4's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 6.4 Logging and Monitoring sits in the mandatory set (26 of the 32 v2026 controls).
Per-host logging coverage with destination and retention — and the part assessors probe: one worked example of an alert handled end to end. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 6.5A — Intrusion Detection is a advisory control in CSCF v2026, sitting in Objective “Detect and Respond”, Principle “Detect Anomalous Activity to Systems or Transaction Records”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
No attestation fails for skipping an advisory control. But the advisory set is where counterparties read maturity, so a practice you already run is worth evidencing in the same format as the mandatory ones.
The active-watching question: beyond logs, is something purpose-built watching for intrusion patterns across the in-scope environment?
The detection capability described with its coverage and a sample of what it raised — an advisory chapter that reads as instant maturity when present.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Detection tuned for the corporate estate that never learned what SWIFT-zone-normal looks like.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 6.5A in full before acting on any summary, this one included.
No. In v2026 it sits in the advisory set of six, which counterparties nonetheless read as a maturity signal.
The detection capability described with its coverage and a sample of what it raised — an advisory chapter that reads as instant maturity when present. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 7.1 — Cyber Incident Response Planning under Objective “Detect and Respond” (Principle: “Plan for Incident Response and Information Sharing”), in the mandatory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
The bad-day question: does the incident-response plan name payment-fraud and SWIFT scenarios specifically — with the SWIFT and counterparty steps in the contact tree — and has anyone rehearsed it?
The plan with SWIFT-specific scenarios plus a dated tabletop or test with findings — the rehearsal record is what separates a plan from a document.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Generic IT-outage plans with no payment-fraud path and no counterparty contact steps.
The authoritative text for control 7.1, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
It is. CSCF v2026 lists 7.1 Cyber Incident Response Planning among its 26 mandatory controls.
The plan with SWIFT-specific scenarios plus a dated tabletop or test with findings — the rehearsal record is what separates a plan from a document. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
In the v2026 framework, control 7.2 — Security Training and Awareness is a mandatory control within Objective “Detect and Respond”, Principle “Plan for Incident Response and Information Sharing”. Below is our own orientation: the point of the control, evidence that tends to carry it, and the common gap. None of it reproduces the control text; read that in full in your own CSCF download.
The people-layer question: do staff holding SWIFT-scope roles get security training that reflects this year's threats, with completion actually tracked?
Training records mapped to the scope-role list, this year's content, completion tracking.
Start there. The rest of the artifact set for this control sits in the paid pack's 26-control checklist, alongside the handover index assessors actually walk.
Annual generic e-learning with no payments-fraud content and no record of who in scope completed it.
v2026 adds deepfake-enabled fraud to the threat examples — including it in this year's content is cheap, current evidence.
Nothing substitutes for the framework document. Control 7.2's full text, guidance and per-architecture applicability sit in the CSCF v2026, downloadable free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0). Verify every statement on this page against it.
Yes: 7.2 Security Training and Awareness sits in the mandatory set (26 of the 32 v2026 controls).
Training records mapped to the scope-role list, this year's content, completion tracking. As the assessor community keeps writing, failures are usually evidence failures. Bring dated artifacts, not assurances.
Control 7.3A — Penetration Testing is a advisory control in CSCF v2026, sitting in Objective “Detect and Respond”, Principle “Plan for Incident Response and Information Sharing”. What follows is orientation in our own words: what the control is getting at, what assessors typically accept, and where submissions fall short. It is not a restatement of the control, which lives in your own CSCF download.
Advisory means what it says: not required for a compliant attestation. Counterparties and assessors still read maturity from the advisory set, and if the practice already exists, evidencing it in the same format costs little.
The adversarial question: has anyone competent tried to break the in-scope environment on purpose, recently?
The latest test's scope and findings with the remediation trail — advisory, and the single strongest maturity signal counterparties read.
That is the headline artifact. The full artifact list for this control, in checklist form with a handover index, is part of the paid evidence pack.
Enterprise-wide pentests whose scope never actually touched the SWIFT zone.
Control text, implementation guidance and per-architecture applicability live in the CSCF v2026 itself. Download it from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, free, no login) and read control 7.3A in full before acting on any summary, this one included.
It is advisory in v2026: not required for a compliant attestation, but widely read as a maturity signal.
The latest test's scope and findings with the remediation trail — advisory, and the single strongest maturity signal counterparties read. Public assessor consensus: most controls fail on evidence, not implementation. Dated artifacts beat assertions.
CSCF v2026 files control 7.4A — Scenario-based Risk Assessment under Objective “Detect and Respond” (Principle: “Plan for Incident Response and Information Sharing”), in the advisory set. This page orients rather than restates: the aim of the control, the evidence assessors tend to accept, and the usual failure mode, all in our own words. The control text itself belongs to your own CSCF download.
No attestation fails for skipping an advisory control. But the advisory set is where counterparties read maturity, so a practice you already run is worth evidencing in the same format as the mandatory ones.
The imagination question: have you walked concrete attack scenarios against your own architecture and drawn conclusions — rather than only maintaining a generic risk register?
A dated scenario exercise: the scenarios, what they revealed, what changed as a result.
Treat that as the lead item: the complete per-control artifact list, formatted as a checklist with an assessor handover index, ships in the paid evidence pack.
Risk registers that list categories while no one ever played out how an attacker crosses this environment.
The authoritative text for control 7.4A, with its implementation guidance and the applicability grid, is the CSCF v2026 itself: free from SWIFT's Knowledge Centre (publication page cscf_dd/70.0, no login). Read it in full before acting on any summary, ours included.
No. In v2026 it sits in the advisory set of six, which counterparties nonetheless read as a maturity signal.
A dated scenario exercise: the scenarios, what they revealed, what changed as a result. The public assessor consensus is blunt: controls fail on evidence more often than on implementation, and an artifact with a date beats an assurance.
The SWIFT CSP Evidence Pack: the v2026 delta map, the architecture & scoping worksheet, the control 2.4 evidence workbook, the full 26-control evidence checklist, the independent-assessment and attestation runbooks, the service-bureau file and the update tracker — independent, built from public assessor consensus. Most controls fail on evidence, not implementation; this pack is the evidence layer.
Get the pack — US$390 Free 4-page sample (PDF)Instant download · 14-day unconditional refund · single-organisation licence · full product page
Independent publication by Kilde — not affiliated with, endorsed by, or approved by S.W.I.F.T. SC. SWIFT is a registered trademark of S.W.I.F.T. SC. Controls are identified by number and short official title only; nothing on this page restates SWIFT's controls text, and all descriptions are our own orientation built from public assessor material — not legal advice, not security consulting, not an independent assessment. Download the CSCF v2026 yourself from SWIFT's Knowledge Centre (publication page cscf_dd/70.0 — free, no login) and verify everything against it. © 2026 Kilde.
Built by Kilde's founder, a practising attorney admitted to a US state bar (not an EU or Hong Kong admission). About · Verification log · Refunds · Terms · Privacy · esau@trykilde.com