A practical CSCF v2026 readiness guide for financial institutions preparing for independent assessment and KYC-SA attestation.

What a SWIFT CSP assessment is designed to establish

The SWIFT Customer Security Programme (CSP) requires SWIFT users to assess their security controls against the Customer Security Controls Framework (CSCF) and support the annual KYC-Security Attestation with an independent assessment. The assessment is point-in-time: it looks at whether the applicable controls are appropriately designed and implemented when the assessment is performed.

That distinction matters when preparing evidence. A policy can describe the intended process, but the assessor will usually need implementation evidence as well. For an access-control requirement, that may mean the current user population, an access-review record, approval evidence and proof that identified access changes were completed. For network segregation, a diagram is useful, but firewall rules, route configurations and configuration evidence are what show that the boundary is enforced.

Assessment conclusions should follow SWIFT's assessment terminology and the organization's actual compliance position. Where an applicable control is not fully met, the finding and any remediation commitment should be reflected accurately in the assessment and KYC-SA process.

What changed for CSCF v2026

The SWIFT CSCF v2026 framework makes scoping particularly important for institutions that use back-office integrations, middleware, file-transfer tooling or other customer-side connectors. Control 2.4A, Back Office Data Flow Security, moved into the mandatory baseline for the relevant 2026 scope. Customer client connectors also moved into mandatory scope, which can change the architecture classification and the controls that apply.

The practical consequence is simple: do not carry last year's architecture classification or evidence pack forward without checking the current environment. A new connector, changed payment flow, service-bureau integration or bridging host can change the assessment boundary.

Start with architecture and scope

SWIFT architecture classifications include A1, A2, A3, A4 and B. The correct classification depends on the way the institution connects to and operates its SWIFT environment. The current CSCF and the actual implementation should be used together; an architecture label on its own is not a substitute for reviewing the technical flow.

In practice, the scoping discussion should identify every system that participates in the SWIFT transaction path, the trust boundaries around those systems, and the party responsible for each control. Particular attention should be paid to customer client connectors, middleware, file-transfer clients, API consumers and bridging systems.

Control 2.4A and customer client connectors

Control 2.4A focuses on the protection of back-office data flows connected to the SWIFT environment. For 2026, institutions should identify the relevant flows, document where they cross trust boundaries, and show how confidentiality and integrity are protected. If a customer client connector is present, the institution should also confirm whether its previous architecture classification remains correct.

Third-party and service-provider boundaries

Using a Service Bureau, cloud provider or other outsourced service does not remove the SWIFT user's responsibility for its CSP attestation. The assessment should make the shared-responsibility boundary explicit and establish what assurance is available for controls operated by the provider. Where another assurance report is relied on, its scope and control coverage should be checked against the components and controls relevant to the SWIFT user.

Evidence to prepare before fieldwork

There is no single evidence pack that fits every SWIFT user. Evidence depends on architecture, control applicability and implementation. The most useful preparation is a control-mapped repository containing current evidence and, where a control represents a recurring activity, suitable samples showing that the process operates in practice.

Governance and security documentation

• Security policies and standards that clearly apply to the in-scope SWIFT environment.
• Privileged-access governance, approval records and current role definitions.
• SWIFT-related incident response procedures and escalation contacts.
• Risk treatment or formally approved risk-acceptance records where relevant.

Identity and privileged access

• Current account listings for relevant SWIFT applications, operating systems and supporting platforms.
• Privileged-account inventories, role mappings and break-glass procedures.
• MFA configuration evidence for applicable administrative and user access paths.
• Periodic access-review records, including approval and evidence of resulting access changes.
• Joiner, mover and leaver samples showing timely provisioning or de-provisioning.

Network and architecture

• Current network and data-flow diagrams showing the SWIFT secure zone and relevant trust boundaries.
• Firewall rules, route information and rule-review evidence.
• Evidence of internet exposure restrictions and network isolation.
• Data-flow documentation for relevant back-office and connector paths under Control 2.4A.

Vulnerability and patch management

• Vulnerability scan results for applicable in-scope systems.
• Remediation records showing how findings were tracked against internal deadlines.
• Approved exceptions or risk acceptances for findings that remain open.

Logging, monitoring and incident response

• Logging configuration for relevant servers, network devices and security platforms.
• SIEM use cases or detection rules relevant to the SWIFT environment.
• Alert-triage records or investigation samples that show operational monitoring.
• Incident-response exercise or tabletop records where required by the applicable control set.

Physical and third-party assurance

• Physical-access evidence where SWIFT components are hosted on premises.
• Relevant service-provider assessment or assurance reports.
• A responsibility matrix showing which party implements and evidences each outsourced control.

Evidence matrix: illustrative examples

The table below is a preparation aid rather than an official SWIFT evidence list. The evidence needed in a real assessment depends on the applicable control, architecture and implementation.

Common gaps that slow an assessment

1. Privileged accounts do not match authorized records. Directory groups, local administrator accounts or database roles contain identities that are absent from the approved entitlement list.
2. MFA is strong on the main portal but weak on secondary administration paths. Jump hosts, consoles, hypervisors or other administrative interfaces can be overlooked.
3. Network diagrams and live firewall rules disagree. Temporary or legacy rules remain active even though the diagram shows a clean boundary.
4. A customer client connector is omitted from scope. Middleware, batch-transfer tools or API consumers sit in the transaction path but were not included in the architecture review.
5. Scanning exists, but remediation evidence is incomplete. A scan report alone does not show that findings were closed, accepted or tracked within the organization's process.
6. Logs are collected but operational review cannot be shown. The SIEM receives events, but there is little evidence of triage, investigation or escalation.
7. Incident response exists only as a document. The plan is current, but there is no evidence of testing or validation where the applicable control calls for it.
8. Access reviews lack closure evidence. The review was performed, but sign-off or proof of resulting access changes is missing.
9. Third-party control ownership is unclear. A provider is relied on, but the institution has not mapped its assurance coverage to the components and controls in scope.
10. Policies are submitted in place of implementation evidence. The document explains what should happen but does not show what is configured or what actually occurred.

Policy is not the same as evidence

A policy records the organization's intended control. The assessment still needs evidence that supports the point-in-time conclusion. Useful examples include configuration exports, access-review approvals, remediation tickets, approved exceptions, alert-triage records and exercise reports. The right question for each artefact is: what control conclusion does this evidence support?

Gap assessment and independent assessment serve different purposes

A readiness or gap assessment is preparatory. It is used to find unclear scope, missing evidence and control weaknesses before formal fieldwork. An independent assessment is the formal evaluation whose conclusions support the organization's KYC-SA attestation.

For organizations with a complex architecture or a weak evidence pack, beginning readiness work around 60 to 90 days before formal fieldwork is a sensible planning window. It gives system owners time to resolve scope questions, obtain third-party assurance and close issues without concentrating all remediation at the end of the attestation cycle.

SWIFT CSP assessment readiness checklist

60 to 90 days before assessment

☐ Verify the architecture classification against CSCF v2026 and the current technical environment.

☐ Identify customer client connectors, middleware, bridging systems and relevant back-office data flows.

☐ Confirm the applicable CSCF controls and assign a named owner to each one.

☐ Build an evidence inventory mapped to control IDs.

☐ Review open findings and remediation commitments from the previous assessment cycle.

☐ Check vulnerability-management evidence for applicable in-scope assets, including remediation and approved exceptions.

☐ Verify MFA across relevant console, administrative and jump-host paths.

☐ Compare firewall and routing configurations with the current architecture diagrams.

☐ Review logging, monitoring and alert-triage evidence.

☐ Confirm the incident-response evidence needed for the applicable control set.

☐ Obtain current assurance material for Service Bureaus and other relevant providers.

Around 30 days before assessment

☐ Review evidence quality and remove artefacts that do not support a control conclusion.

☐ Close overdue technical findings or document approved exceptions.

☐ Prepare access-review and JML samples.

☐ Draft management responses and target dates for known open items.

☐ Run an internal readiness review with the technical and control owners.

Immediately before fieldwork

☐ Finalize the evidence repository by CSCF control number.

☐ Confirm availability of the administrators, network team, security operations team and other relevant owners.

☐ Nominate one assessment coordinator for evidence requests and assessor queries.

☐ Prepare closure evidence for prior findings and remediation commitments.

☐ Reconfirm that no material architecture or connector changes occurred after scope was agreed.

Where penetration testing fits

Control 7.3A, Penetration Testing, remains an advisory CSCF control in v2026. It should therefore be described as advisory unless another regulatory, contractual or internal requirement makes testing mandatory for the institution. A SWIFT-focused penetration test can still be valuable technical evidence because it tests whether segmentation, access controls and other defences resist realistic attack paths.

Where DORA or another regime also applies, there may be an opportunity to coordinate testing programmes. Any reuse of testing evidence should be based on a deliberate scope mapping; a penetration test designed for one framework should not be assumed to satisfy another framework automatically.

How RedSecLabs can support the assessment cycle

RedSecLabs is listed as a SWIFT CSP assessment provider and works with SWIFT CSP Certified Assessors. Support can be scoped around the stage the institution is at, from architecture and evidence readiness through to independent assessment fieldwork.

• Architecture and scope review: confirm the connectivity model, customer client connectors, back-office flows and applicable control boundary.
• Readiness and gap assessment: test the evidence pack and identify control or documentation gaps before formal fieldwork.
• Independent assessment: assess applicable CSCF controls under the required independence and competency criteria.
• Remediation support: help control owners address findings and prepare closure evidence.
• KYC-SA support: organise assessment outputs, management responses and supporting evidence for the attestation process.

For organizations approaching the 2026 attestation window, the most useful first step is usually a short architecture and evidence review. It establishes whether the scope is correct before time is spent refining the evidence pack.

SWIFT CSP assessment FAQs

Q1: What is a SWIFT CSP assessment?

Ans: A point-in-time independent evaluation of whether the applicable CSCF controls are appropriately designed and implemented. Its conclusions support the organisation's annual KYC-SA attestation.

Q2: What evidence is required?

Ans: There is no universal evidence pack. Evidence depends on architecture, applicable controls and implementation. Typical material includes access records, configuration evidence, vulnerability and remediation records, monitoring evidence, incident-response documentation and third-party assurance.

Q3: How does architecture affect scope?

Ans: Architecture is a key input to control applicability and the assessment boundary. The current CSCF should be read against the actual connectivity and system design, particularly where connectors or outsourced services are involved.

Q4: What is the difference between a gap assessment and an independent assessment?

Ans: A gap assessment is preparatory and is used to identify weaknesses before formal fieldwork. The independent assessment is the formal evaluation supporting the KYC-SA attestation.

Q5: How often is KYC-SA completed?

Ans: SWIFT users complete the security attestation annually. Scope and control applicability should be checked against the CSCF version applicable to the relevant attestation cycle.

Q6: What happens when a control gap is found?

Ans: The organisation should record the actual status, address the gap and retain evidence of remediation. Where remediation changes an assessment conclusion, further assessment work or evidence may be needed.

Q7: What is KYC-SA?

Ans: KYC-Security Attestation is the SWIFT application used by organizations to submit their annual security attestation and declared compliance position.

Q8: How long does an assessment take?

Ans: The time required depends on architecture complexity, the number of applicable controls, third-party dependencies and evidence readiness. Clear scope and a well-organized evidence repository reduce avoidable delays.

Speak to RedSecLabs

If you are preparing for a CSCF v2026 assessment, RedSecLabs can review the architecture, confirm the evidence boundary and identify gaps before independent fieldwork begins.

Contact RedSecLabs to discuss SWIFT CSP readiness or independent assessment requirements

Media enquiries

RedSecLabs
[email protected]
+44 20 3996 1505