SWIFT CSCF vs SOC 2

SWIFT CSCF vs SOC 2: which to pursue first and when to do both

If you run a service bureau or Swift service provider and your customers ask for both documents, start with the CSCF. The CSCF attestation is mandatory for Swift users and is filed in the KYC-SA application each year, so any institution connected to Swift needs it regardless of what its customers request. A SOC 2 report is a CPA report that a customer requests under contract, usually because the customer's own vendor risk process or auditors require it. Neither document replaces the other: a SOC 2 report says nothing about whether a customer's Swift-connected environment meets the CSCF controls, and a CSCF attestation does not tell a buyer how your service's controls were tested over a period.

The sequencing question is therefore really about who is asking and what they will accept. A Swift user that outsources its messaging operations should confirm with each customer whether a SOC 2 Type 1 or Type 2 report, a SOC 3 report, or only the CSCF attestation will satisfy its due diligence, and whether the customer's auditors expect the report to cover the Swift-related services specifically. Check the scope and the trust services criteria chosen in any SOC 2 before relying on it for Swift questions, because the CSCF controls cover Swift-connected infrastructure that a general SOC 2 may not describe. Note also that SOC 2 use is generally restricted, so confirm the recipient list before distribution.

When the customer's requirements overlap, a practical order is to complete the current CSCF cycle first, since non-compliance is visible to supervisors, then scope the SOC 2 so that its system description and controls reuse the CSCF evidence where the boundaries match. Ask your assessor and your SOC 2 auditor, early and in writing, which evidence each will accept from the other. Doing both is worth it when customers contractually require SOC 2 coverage and the CSCF evidence set can be reused without distorting either scope. Illustrative example: a bureau whose only customer question is about Swift connectivity may find the CSCF attestation sufficient, while one serving card and treasury clients may need both.

How the CSCF and SOC 2 differ on scope, proof and cycle

This table compares who requires each framework, what it covers, the report it produces, who may read that report and how the annual cycle runs. Read it as a guide to which evidence each customer or regulator will expect, not as a claim that one replaces the other.

Dimension	SWIFT CSCF (v2026)	SOC 2
Who requires it	Every Swift user must implement the controls, have them independently assessed and attest annually in KYC-SA	No mandate in the supplied facts. Customers of a service organization typically ask for it contractually, so confirm the requirement with each customer
What it covers	The user's own Swift-connected infrastructure, organized into three objectives: secure your environment, know and limit access, and detect and respond	A service organization's system against chosen Trust Services Criteria, with security always in scope and other categories added only when selected
Structure	32 controls: 26 mandatory and 6 advisory, with controls in scope based on one of five architecture types (A1, A2, A3, A4 and B)	Common criteria CC1 to CC9 always apply. Availability, confidentiality, processing integrity and privacy add criteria only when included in scope
Report or proof produced	An attestation filed in the KYC-SA application for Swift	A CPA report with a Type 1 opinion on control design at a date, or a Type 2 opinion that also covers operating effectiveness over a period
Who can use the output	Swift may report users without a valid attestation or not compliant with mandatory controls, and supervisors can see non-compliance	Use is generally restricted to specified parties. A SOC 3 report is a general use alternative, but it covers the same categories in less detail
Assessor	Internal (second or third line, such as risk, compliance or internal audit) or external, with Swift's Assessor Certification optional	A licensed CPA firm performing an attestation examination under AT-C section 205
Annual cycle	Attestation against CSCF v2026 runs between July and December 2026, with new versions published each July ahead of application	Type 1 is a point-in-time review and Type 2 covers an observation period. Confirm the period and report date with the auditor

Who needs the CSCF, who needs SOC 2, and why service bureaus get both

Every Swift user must attest for its own infrastructure, and a service bureau is a Swift user in its own right when it connects to Swift for its own business. The Customer Security Programme requires each user to implement the CSCF controls that apply to its connectivity, have them independently assessed through a Community Standard Assessment, and attest annually in the KYC-SA application. A bureau's CSCF attestation covers the systems it operates to reach Swift itself, including its own operator and messaging infrastructure. Swift's independent assessment may be run by internal second or third line functions such as risk, compliance or internal audit, or by an external assessor, and the CSP Assessor Certification is optional. Before planning the cycle, confirm which CSCF v2026 architecture type applies to each connection with the bureau's Swift contacts, since that determines which controls are in scope.

SOC 2 answers a different question. It is a CPA report, prepared under AT-C section 205 of the AICPA attestation standards, that describes the bureau's service and tests the controls chosen for the trust services criteria in scope. Customers that route payment or messaging work through the bureau usually ask for it because they want assurance over how the service operates, not over the bureau's Swift attestation. Illustrative example: a bureau's customer asks for a SOC 2 Type 2 report covering security and availability, and the bureau delivers it, but the customer's own Swift attestation still depends on the bureau's independent CSCF evidence for the connection the bureau operates. Each report is a separate deliverable with its own owner, scope and period, so neither one can stand in for the other.

The practical decision is to map the customer's questions to each report before scoping either engagement. Ask which Swift-related controls the customer relies on, which trust services criteria the customer expects in the SOC 2, and whether the customer will accept a SOC 2 Type 1 or needs a Type 2 covering an operating period. Then agree the timing so the SOC 2 period and the CSCF cycle, which runs from July to December for CSCF v2026, do not leave evidence gaps. Confirm with the assessor and the customer whether SOC 2 use is restricted, since a SOC 2 report is generally restricted while a SOC 3 report can be freely distributed.

Where SOC 2 evidence overlaps the CSCF and where it does not

Swift says each CSCF control is defined in line with recognized standards including SOC 2 and NIST CSF, so a SOC 2 report can inform evidence for matching controls. It does not replace CSCF evidence, because scope, system boundary and the Swift footprint differ. The four areas below show where overlap is most likely and where gaps tend to appear.

Access control and privileged identities

The CSCF objective to know and limit access covers credentials, identities and privileges on the Swift footprint. SOC 2 addresses logical access in common criteria CC6, but the auditor tests only the systems inside your service boundary. Check whether Swift operator accounts, interface servers and administrator roles appear in the SOC 2 system description. If they are missing, the report cannot evidence them for the CSCF, and you will need separate access reviews.

Logging and monitoring

The CSCF detect and respond objective expects anomaly detection across the Swift-connected environment. SOC 2 system operations criteria in CC7 require monitoring of system components, which overlaps with this work. However, a monitored population in a SOC 2 may cover only the in-scope service. Confirm that Swift-related logs, retention periods, time synchronization and alert review ownership are included in the monitored population the auditor sampled.

Change management of Swift components

SOC 2 change management sits in common criteria CC8, where the auditor samples changes to in-scope systems and tests approval and testing. CSCF controls on hardening, patching and configuration of Swift infrastructure apply to the Swift footprint, which may include components outside the SOC 2 boundary. Ask whether the sampled changes include Swift middleware, connectivity components and emergency changes, and whether the Type 2 observation period covered them.

Incident response and information sharing

The CSCF detect and respond objective includes incident response and information sharing. SOC 2 incident handling falls under the system operations criteria, and the auditor checks whether your process was designed and operated for the in-scope service. The Swift-specific scenarios in your plan are a separate question. Check that the playbook covers Swift-related compromise, escalation paths to the security function and the reporting steps your Swift obligations require.

Who assesses each framework and what each assessment issues

This table compares who performs the CSCF independent assessment and the SOC 2 examination, and what each one produces for the reader. Use it to see which evidence a Swift attestation and a SOC 2 report can each support, and where one cannot stand in for the other.

Aspect	SWIFT CSCF	SOC 2
Who performs the assessment	Internal second or third line function such as risk, compliance or internal audit, or an external assessor	A CPA firm acting as service auditor under AT-C section 205
Assessor credential	Swift's CSP Assessor Certification is optional	The examination is performed by a CPA firm under the AICPA attestation standards
Who sets the scope	Swift defines the controls and the architecture type that applies to the user's setup	The service organization chooses the trust services criteria and systems in scope
Primary output	Independent assessment supporting the annual KYC-Security Attestation filed in KYC-SA	A CPA's report with a system description and an opinion on the controls
Type 1 versus Type 2	Not applicable; one annual assessment cycle tied to the CSCF version	Type 1 covers control design as of a date; Type 2 adds operating effectiveness over a period
Use restrictions	Attestation is filed with Swift and visible to supervisors when non-compliant	SOC 2 use is generally restricted to specified parties; a SOC 3 report is general use and freely distributable
What customers can rely on	Confirms a Swift user's own Swift-related infrastructure controls	Confirms controls over the service organization's system for the scope chosen; confirm which report type your customers need

Sequencing the CSCF attestation and a SOC 2 engagement

This sequence confirms the Swift scope first, completes the independent assessment that supports the KYC-Security Attestation, and then aligns the SOC 2 system description so shared evidence is reused without misstating either scope. Each report stays a separate deliverable with its own boundary.

Confirm Swift architecture type and CSCF v2026 scope
Identify how each Swift connection is made and which architecture type applies, from A1, A2, A3, A4 or B. The architecture type determines which CSCF v2026 controls are in scope, and the CSCF v2026 publication lists 32 controls, 26 mandatory and 6 advisory. Your Swift security lead and infrastructure owner should sign off a written scope statement listing the in-scope systems, connectivity paths and people. The step is done when that statement is approved and stored with the attestation file.
Map CSCF controls to the in-scope infrastructure
Document how each applicable CSCF v2026 control is implemented on the Swift footprint, including owners, configuration evidence and operating records. Work through the three objectives, secure your environment, know and limit access, and detect and respond, so no in-scope control is left without an owner. Compliance and security engineering should review the map together. The step closes when every mandatory control has a named owner and a located evidence source.
Complete the Community Standard Assessment
Arrange the independent assessment that every Swift user must complete each year to support its KYC-Security Attestation. The assessor may be internal, from a second or third line function such as risk, compliance or internal audit, or external, and Swift's CSP Assessor Certification is optional. Confirm with Swift's current guidance which assessor types are acceptable for your situation. The step closes when the assessment result is recorded against the CSCF v2026 scope.
Submit the KYC-Security Attestation
Using the assessment results, complete the annual KYC-Security Attestation in the KYC-SA application for the CSCF version in force. CSCF v2026 is the version users attest against between July and December 2026. Check the submitted answers against the assessment record so the attestation does not claim more than the assessor tested. The step is complete when the attestation is accepted and the submission record is archived.
Define the SOC 2 system description and criteria
Scope the SOC 2 examination around the service that customers buy, which may or may not include the Swift messaging service. Management prepares the system description against the AICPA 2018 description criteria, and selects the trust services categories and criteria with the CPA firm. Decide explicitly whether Swift-connected components sit inside the system boundary. The step closes with an approved draft of the system description and criteria list, reviewed by the CPA firm before fieldwork.
Reconcile shared evidence between the two scopes
Compare the CSCF evidence set with the SOC 2 control evidence and note where the same artifact supports both, such as access review records, change logs or monitoring alerts. Reuse an artifact only where its scope, period and population match each report, and where the auditor accepts it. Record every reused item with its boundary so neither report implies coverage it does not have. The step is done when a signed reconciliation register exists for both teams.
Keep the two reports separate and dated
Issue the CSCF attestation and the SOC 2 report as separate deliverables, each with its own scope statement and date. A SOC 2 Type 1 covers the design as of a date, and a Type 2 covers operating effectiveness over a period, so the periods will not match the annual CSCF cycle. Brief customers that the SOC 2 report supports but does not replace the Community Standard Assessment. The step closes when customer-facing language has been reviewed for accuracy.
Plan the next annual cycle from the CSCF calendar
Track each new CSCF version published by Swift, which is issued every July a year before it applies, and the up-to-18-month preparation window for new or changed controls. Use these dates to schedule the next assessment and to update the architecture scope and reconciliation register. Ask the SOC 2 auditor to align the observation period where practical. The step is complete when the next cycle has an owner, a scope review date and a change log.

What drives the cost and effort of each engagement

The biggest cost difference between these two engagements is who does the work. On the CSCF side, the annual Community Standard Assessment can be performed internally by a second or third line function such as risk, compliance or internal audit, or by an external assessor. Swift's CSP Assessor Certification is optional, so your budget depends on whether you use internal staff, an external firm or a mix. Remediation is a separate cost in both cases: fixing gaps in the Swift footprint, such as segregation of the connected environment or privileged access, is paid for in engineering time or vendor work. Before you ask for a quote, confirm which architecture type applies to your connection, because that determines which of the 32 CSCF v2026 controls are in scope and therefore how much assessment effort you should expect.

SOC 2 costs sit in different places. You pay the CPA firm for the examination itself, and the fee moves with the Trust Services Criteria you include, the audit period (Type 1 is a point-in-time review, Type 2 covers a period of operating effectiveness) and the number of systems in scope. Internal effort goes into preparing the system description against the AICPA description criteria, gathering evidence across the operating period and answering auditor requests. Remediation of control gaps found during testing is usually the largest variable, and it is often incurred more than once if the first testing period surfaces failures. Recurring costs in both frameworks are the annual cycle itself, while one-time costs include the initial readiness work, tooling and any remediation backlog.

When you request a written quote from DeployOpen, ask for the scope in writing before the price: which controls or criteria, which environments and which deliverables, such as system description support, evidence collection, control testing preparation or remediation. DeployOpen does not publish a price list, and a quote follows from the written scope that both sides agree before work starts. Ask the quote to separate one-time work from recurring work, to state which items depend on your own staff time, and to name any assumptions about existing evidence you can reuse for both the CSCF attestation and a SOC 2 report. Confirm with your CPA firm and with Swift's published guidance which items they will accept, so that a single evidence set does not get paid for twice.

Questions service bureaus ask before choosing an approach

Does a SOC 2 report satisfy the CSCF attestation?

No. A SOC 2 report cannot replace the CSCF attestation, because every Swift user must complete a Community Standard Assessment each year to support its KYC-Security Attestation. A SOC 2 examination is a CPA report on the controls you chose to cover against the AICPA Trust Services Criteria, while the Community Standard Assessment tests your Swift footprint against the CSCF controls for your architecture type. The useful overlap is evidence. Access reviews, change records, monitoring and incident logs gathered for a SOC 2 can be offered to the assessor, but the assessor still has to test the CSCF controls that apply to you. Confirm the exact mapping with Swift's published controls and your assessor before you plan the evidence set.

Can we run the CSCF assessment internally?

Possibly, but only if the people doing it are independent of the work they assess. Swift's Independent Assessment Framework allows the assessment to be internal, carried out by a second or third line function such as risk, compliance or internal audit, or external. Swift's CSP Assessor Certification is optional, so an internal team does not need it to be eligible, although your customers and supervisors may ask how the assessors were qualified. Internal teams usually carry the cost of staff time and tooling, while external assessors are a recurring fee set by their written scope. Ask Swift and your supervisor whether an internal assessment is acceptable for your architecture type and how they expect independence to be demonstrated.

How long does each approach take, and what drives the timing?

The timing depends on scope and on your own evidence, and no fixed duration is supplied here, so ask each provider for a written plan. A SOC 2 Type 2 covers an observation period, which means the controls must operate across that window before the auditor can give an opinion on operating effectiveness. A Type 1 is a point-in-time review of control design. The CSCF runs on Swift's annual cycle: CSCF v2026 is the version attested between July and December 2026, and Swift publishes each new version a year before it applies. The main drivers are the number of systems in scope, how many architecture types you run, how current your documentation is, and how quickly the assessor can access evidence. Plan the two work streams together so one evidence collection serves both.

What does each approach require from management and engineering?

Both require named owners, written procedures and evidence that controls ran, but the weight falls differently. For a SOC 2, management must prepare a description of the system and give written representations to the service auditor under AT-C section 205, so senior leaders must sign off on what the report says. For the CSCF, engineering must implement the controls that apply to your architecture, such as restricting internet access, managing privileged credentials and monitoring for anomalies, and the assessor must see them working. Expect engineering to spend time on configuration evidence, access reviews and log retention, and expect management to own the attestation decision. Ask both providers who on your team must be available and for how many working sessions.

Is a SOC 2 Type 1 enough for our customers?

It depends on what your customers ask for. A Type 1 report describes your system and whether control design was suitable as of one date, but it gives no opinion on whether controls operated over time. Many customers who ask for SOC 2 expect a Type 2 for that reason, and some will ask for a bridge letter covering the period since the report date. A Type 1 also does not change the CSCF position: your Swift attestation still depends on the Community Standard Assessment. If a customer asks for a SOC 3, note that SOC 3 reports are general use and can be freely distributed, while a SOC 2 report is generally restricted. Confirm with each customer which report and period their contract or due diligence requires.

Does DeployOpen issue SOC 2 reports or CSCF attestations?

No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors issue SOC 2 reports, and Swift users attest to the CSCF through their own KYC-Security Attestation supported by an independent assessment. DeployOpen prepares systems, controls and evidence for compliance assessments, and it can plan, implement, harden and document the self-hosted platforms in your infrastructure so the assessor has clear material to test. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Ask for the written scope, the named assessor relationship and the evidence list before you commit.

What to confirm with Swift, your CPA firm and your customers

Start by confirming your CSCF architecture type, because it decides which controls are in scope for your attestation. Swift describes five architecture types (A1, A2, A3, A4 and B), and the applicable set depends on how your institution connects to Swift. Check your current type against the CSCF v2026 document and the Swift CSP Understand controls page before your SOC 2 scope is drawn, so the service bureau's SOC 2 system description covers the Swift-related infrastructure your customers actually rely on. Ask Swift or your KYC-SA administrator to confirm which controls apply to your own footprint, and do not assume a customer's architecture matches yours.

Next, confirm the assessor. Swift allows the independent assessment to be internal, by a second or third line function such as risk, compliance or internal audit, or external, and its CSP Assessor Certification is optional. Ask your CPA firm whether its staff hold that certification or otherwise meet the assessor expectations in Swift's independent assessment guidance, and ask how it will handle independence if the same firm writes your SOC 2 and performs your Community Standard Assessment. Also ask customers which trust services categories they expect in the SOC 2 report. Security is always covered, but availability, processing integrity, confidentiality and privacy add criteria only when they are in scope, and a scope chosen without customer input can leave a gap you discover during the Swift review.

Finally, agree the testing period and plan for standards change. A Type 2 report covers operating effectiveness over a period, so ask your CPA firm to state the period, the sampling approach and how evidence from it maps to the CSCF controls you attest to each year. Also ask counsel and the CPA firm about the AICPA Auditing Standards Board's February 2026 proposal to revise the baseline attestation standards, which would apply to engagements beginning on or after June 15, 2029 if adopted. Put that date into your planning calendar, and ask each party how a change in attestation standards would affect report wording, management representations and the reuse of evidence.

How DeployOpen prepares evidence for both frameworks

DeployOpen works on SWIFT CSCF vs SOC 2 as an implementation and evidence partner inside your own infrastructure. We scope the Swift footprint and the SOC 2 system boundary separately, then build controls and evidence that can serve both without claiming either report on your behalf.

How we scope

Written scope names the Swift connectivity architecture, systems and connected environments covered by the CSCF work.
Scope also defines the SOC 2 system boundary, chosen trust services criteria and whether the report is Type 1 or Type 2.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We implement and document controls on the Swift-related infrastructure against the CSCF v2026 control set in scope.
We map shared controls to SOC 2 criteria so one control operation produces evidence usable for both assessments.
We run security testing on in-scope systems and record findings, remediation and retest results for assessor review.

How we hand over

Handover includes control documentation, evidence libraries and the mapping between CSCF controls and SOC 2 criteria.
We prepare evidence for your internal assessor or external assessor, but independent assessors and the AICPA process issue the results.
Deliverables are documented so your own team can maintain evidence collection between annual cycles.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for the CSCF and SOC 2 environment.
Retainers can cover control updates when Swift publishes a new CSCF version each July, ahead of its application date.
Confirm with your assessor and Swift which evidence formats and reviewer expectations apply to your attestation cycle.