SWIFT CSCF Control 2.8 Preparation Guide | Threat Manifest

The assessor's request arrived on a Tuesday: the control 2.8 evidence package — contracts, risk assessments, and the outsourcing agent's compliance report. By Thursday, the bank's GRC lead had found the problem. The SOC 2 report they had filed as evidence didn't cover the SWIFT environment at all. The scope excluded production. Three years of attestations. One assumption never tested. Control 2.8 is where that assumption breaks.

SWIFT CSCF control 2.8 — Outsourced Critical Activity Protection — is the control where outsourcing risk becomes an assessor's problem to evaluate and a bank's problem to evidence.

Harder than they expect.

Control 2.8 — Outsourced Critical Activity Protection — is one of the controls where I consistently see the gap between what a bank thinks it has documented and what an assessor actually needs to conclude compliance. It is also one of the most consequential controls in the SWIFT CSP framework because its non-compliance cascades into every other mandatory control where a third party is involved. The policy exists. The vendor contract exists. But the evidence that those policies are being operationally enforced against the specific third parties touching their SWIFT infrastructure? That's usually where things get thin.

This article breaks down what the control actually requires, who it applies to, what "reasonable comfort" from a third party actually means in practice, and — most importantly — what evidence you need to have ready before an assessor walks in.

What the SWIFT CSCF Control 2.8 Actually Requires

The formal control objective for 2.8 is to ensure the protection of the bank's SWIFT infrastructure from risks introduced by outsourcing critical activities to third parties. In plain language: if someone else is operating, hosting, or managing any part of your SWIFT environment, you remain responsible for ensuring they are doing it to at least the same security standard as if you were doing it yourself.

This is not a risk transfer. Outsourcing the activity does not outsource the compliance obligation.

The control statement is clear: critical outsourced activities are protected, at a minimum, to the same standard of care as if operated within the originating organisation.

Control 2.8 applies across all SWIFT architecture types — A1, A2, A3, A4, and B. There is no architecture where it becomes irrelevant. And critically, SWIFT notes that even when outsourced activities are not classified as critical, the control remains strongly recommended. The mandatory threshold is crossed the moment any activity SWIFT defines as critical moves to a third party.

It became a mandatory control from CSCF v2024 onwards. For CSCF v2026, nothing about the core requirement has changed — but the Outsourcing Agents Security Requirements Baseline v2026 that sits alongside it has been updated, and understanding that document is essential to properly assess and evidence this control.

Outsourcing the activity does not outsource the compliance obligation.

SWIFT CSCF control 2.8 objective

What SWIFT Defines as "Critical Activity"

This is where most banks make their first mistake. They assume "critical" is something they get to define based on their own risk appetite. It is not. SWIFT provides a minimum list of activities it considers critical regardless of how any individual bank classifies them.

At a minimum, SWIFT defines the following as critical activities when they relate to a bank's SWIFT infrastructure:

Security and change management of hardware and software — including HSMs, applications, the operating system, and the underlying virtualised platform or infrastructure. If a third party is patching your Alliance Access server or managing your HSM, that is a critical activity.

RMA and Business Transaction Controls operations — activities in support of controls 2.9 and 2.11. Any third party involved in Relationship Management Application (RMA) operations or business transaction controls falls within scope.

Access to sensitive user data — this includes message content. If a vendor's staff can see the content of SWIFT messages as part of their managed service, that is in scope.

Monitoring of events containing sensitive user data — SOC services that monitor SWIFT-related logs and events where message content is visible are in scope.

Network management and configuration — firewall rule changes, network device management, routing configuration touching the secure zone.

SWIFT-related transaction operations — including the creation or modification of a business transaction message within an interface or connector. If a vendor's operator can initiate or modify a SWIFT message, this is critical.

Security administration of user entitlements, tokens, or private keys — any managed service responsible for user access provisioning, token lifecycle, or key management for SWIFT operations.

Ancillary services that share credentials or entitlements used for SWIFT operations — when the same accounts used for SWIFT-related transaction operations are also used for other services managed by a third party, those ancillary services are in scope.

One clarification that often surprises banks: external contractors are not automatically considered third-party resources. If a contractor works as part of your internal team using your equipment, they are treated as an employee under the CSCF. However, if they remotely manage or operate your SWIFT components using their own company equipment under a managed service agreement, they are a third-party resource — and control 2.8 applies to them.

Who Qualifies as an Outsourcing Agent — And Who Doesn't

The Outsourcing Agents Security Requirements Baseline v2026 draws a clear distinction between outsourcing agents and Swift Connectivity Providers. Banks need to understand this boundary because it determines who needs to provide what evidence, and how that evidence feeds into the KYC-SA attestation.

An outsourcing agent is a third party to whom a bank either (i) delegates the hosting, installation, operation, or maintenance of SWIFT components it owns — or (ii) connects to use a Swift-related application exposed by that third party (such as a Treasury Management System or middleware server) to manage business transactions before that third party connects to a Swift Connectivity Provider.

Common examples of outsourcing agents include:

• A data centre hosting your Alliance Access instance
• A cloud provider running SWIFT components in an IaaS model (AWS, Google Cloud, Azure are specifically named in the baseline)
• A managed security service provider running your SWIFT environment monitoring
• A vendor whose web-based TMS your operators use to create and approve SWIFT messages
• A service bureau hosting and operating a messaging interface owned by your bank (when the interface is owned by the bank, not the service bureau — that changes the classification)

Who is NOT an outsourcing agent:

• Service providers operating under a Swift provider programme — Service Bureaux, L2BA providers, and Enablers — are not outsourcing agents for the activities covered by their Swift programme. They are Swift Connectivity Providers. However, if a Service Bureau also hosts your bank's own Alliance Access instance separately from its shared infrastructure, it is acting as an outsourcing agent for that specific hosted component.
• User group hubs — entities identified by a BIC or PIC code that are subject to CSP independently.
• SWIFT itself.

For banks using multiple providers, this boundary question can get complicated quickly. A single engagement with a managed service provider might involve activities some of which fall under a Swift provider programme and some of which qualify as outsourcing. Each component needs to be scoped separately.

The Three Ways to Get Reasonable Comfort — And What Assessors Actually Accept

The control requires the bank to obtain "reasonable comfort" from its outsourcing agents that the outsourced activities are maintained in line with the CSCF. The OASRB v2026 identifies three approaches:

From an assessor's perspective, Option 3 produces the cleanest evidence trail. Option 1 is the most common in practice but requires careful scope verification — a SOC 2 report is not automatically sufficient. I have seen assessments where a bank presented a SOC 2 Type II report for a cloud provider, but the report's scope excluded the specific CSCF controls applicable to their SWIFT components, or excluded the production environment entirely. The report existed. The gap in coverage still produced a control 2.8 finding.

The key principle: the outsourcing agent's compliance assessment must cover both mandatory and advisory controls applicable to their in-scope components. The OASRB is explicit that advisory controls must also be reported to the bank, because the outsourcing agent cannot know which advisory controls the bank intends to attest against. For a deeper look at how this comfort standard is evaluated during the assessment itself, see what the IAF actually requires during a SWIFT CSP independent assessment.

What Evidence Assessors Actually Check for Control 2.8

When I assess control 2.8, here is what I am looking to see — not as a checklist to pass, but as a picture of whether the bank genuinely governs its outsourced SWIFT activities.

If you want a structured list of what to prepare before your assessment window opens, the SWIFT CSP Pre-Assessment Evidence Checklist covers control 2.8 alongside every other mandatory control — download it free.

Contractual foundation

• SLA and NDA with each outsourcing agent — not a generic vendor agreement, but an agreement that specifically references the SWIFT Customer Security Programme and defines the security standard under which SWIFT-related activities are performed. The SLA must define the standard of care for critical operations. A blanket IT services contract does not satisfy this.
• Evidence the SLA is maintained and current — not just signed. Assessors will check if there has been a periodic review, particularly when the CSCF version changes or when the outsourcing agent's scope changes.

Risk assessment

• An initial security risk assessment conducted at the start of the outsourcing engagement — covering the specific security risks introduced by outsourcing the SWIFT-related activities to this third party. This is not a general vendor risk assessment. It needs to be specific to SWIFT infrastructure risk.
• Evidence of regular review — the risk assessment must be reviewed on a regular basis. "Regular" is not defined as a specific frequency in the CSCF, but annual review aligned with the attestation cycle is the expected minimum. A risk assessment that was completed three years ago and never reviewed will not satisfy the requirement.

Reasonable comfort evidence

• The assurance report, assessment report, or completion letter from the outsourcing agent covering the mandatory (and advisory) CSCF controls applicable to their in-scope components.
• Scope verification — the bank or its assessor must confirm the coverage is adequate. If there are gaps between the outsourcing agent's report scope and what the CSCF requires, those gaps need to be documented along with how they are mitigated or addressed.

KYC-SA attestation alignment

• Identification of outsourcing agents in the KYC-SA attestation — the control 2.8 section of the KYC-SA form specifically asks whether the bank is using outsourcing agents and requires them to be listed. Assessors confirm this is completed accurately.
• Architecture type alignment — the bank's declared architecture type in the KYC-SA must reflect the most comprehensive architecture type considering all in-scope components, including those hosted or operated by outsourcing agents. If the outsourcing agent hosts a messaging interface (A2) but the bank has only declared A4 because that is its own component, the architecture type is incorrect.

Shared responsibilities

• Evidence that shared controls — particularly MFA for operator access to outsourcing agent entry points, and secure application-to-application connectivity — have been configured by both parties. These shared responsibility controls require bilateral documentation.

If any mandatory control is non-compliant at the outsourcing agent, control 2.8 must also be declared non-compliant in the KYC-SA — regardless of the bank's own compliance posture.

SWIFT CSCF v2026 guidance on cascading compliance levels

The KYC-SA Attestation Trap Most Banks Walk Into

Since CSCF v2024, SWIFT introduced a specific rule that is important and still catches banks off-guard during assessment: if any mandatory control is non-compliant at the outsourcing agent, the bank must declare both the relevant control as non-compliant and control 2.8 as non-compliant in the KYC-SA attestation.

This is not optional. The KYC-SA guidance is explicit: if control 2.2 (Security Updates) is non-compliant at the outsourcing agent, control 2.2 must be declared non-compliant, and control 2.8 must also be declared as non-compliant or "will comply by a given date."

In practice, this means control 2.8's attestation status is partly a function of how every other mandatory control performs at the outsourcing agent. A bank that has clean compliance on its own infrastructure but uses an outsourcing agent with a patching gap will find that gap cascading into a control 2.8 non-compliance as well.

The combining rule for compliance levels across the bank's own infrastructure and its outsourcing agents works on a lowest-wins basis: if the bank is compliant and the outsourcing agent is not, the attestation reflects non-compliance. There is no averaging.

Where Banks Consistently Fall Short

Having assessed control 2.8 across multiple banking clients, these are the failure patterns I see most often:

What Good Looks Like Before Your Assessment Window Opens

Control 2.8 is not something you prepare for in the week before the assessor arrives. The evidence it requires — security risk assessments, SLA reviews, outsourcing agent compliance reports — takes months to properly establish and maintain. Here is what a well-prepared bank looks like when the assessment window opens.

A current and complete inventory of outsourcing agents. Every third party touching the SWIFT environment is identified, their role is documented, and they are correctly classified as outsourcing agents. The boundary between Swift Connectivity Provider activities and outsourcing agent activities is clearly defined where the same vendor plays both roles.

Contracts that specifically reference SWIFT CSP. SLAs define the security standard for SWIFT-related activities. NDAs cover SWIFT data. The agreements have been reviewed in the current attestation cycle.

A risk assessment specific to each outsourcing relationship, covering SWIFT infrastructure risks, reviewed within the past 12 months, and updated whenever scope or CSCF version changes.

Compliance evidence from each outsourcing agent covering the mandatory and advisory CSCF controls applicable to the components they host or operate. The scope of that evidence has been verified against the CSCF controls applicable to the bank's architecture type. Gaps are documented.

Shared controls are configured and evidenced. MFA for operator access to outsourcing agent entry points is operational. Secure A2A and U2A data flows are configured by both parties. Documentation from both sides exists.

The KYC-SA is completed accurately. Outsourcing agents are listed. The architecture type reflects the most comprehensive type across all in-scope components. The control 2.8 compliance level correctly combines the bank's own posture and the outsourcing agents' posture using the lowest-compliance rule.

If You Are Starting This Preparation Now

The first thing to do is scope. Sit down with a copy of the CSCF section on "Scope of Security Controls" and the Outsourcing Agents Security Requirements Baseline document and work through every vendor with any role in your SWIFT environment. Classify them correctly. Determine which components they host or operate. Identify which CSCF controls apply to those components.

Then audit your contracts against the requirements. Most banks find the SLA language is generic and the CSCF is not referenced. That is a remediation conversation with procurement and legal — not something to leave until the week before the assessment.

The evidence chain for control 2.8 — contract, risk assessment, outsourcing agent compliance report, scope verification — has to be complete before an assessor can conclude compliance. Each element takes time to produce or obtain. Start now, not at the start of the attestation window.

If you are working through a SWIFT CSP assessment and want a second opinion on whether your control 2.8 evidence package is going to hold up, that is exactly the kind of conversation I have with banking clients through the consulting engagement. The link is in the sidebar.