SWIFT CSCF vs DORA

SWIFT CSCF vs DORA: which one to pursue first and why you probably need both

If your EU bank or payment institution is connected to Swift, you already face two obligations that overlap in time but not in substance. DORA has applied since 17 January 2025, and the Customer Security Controls Framework (CSCF) is mandatory for every Swift user, which must implement the controls, have them independently assessed, and attest compliance annually in the KYC-SA application. DORA is a regulation supervised by competent authorities and produces no certificate. The CSCF produces an attestation that Swift can see and that your supervisors can see. Our recommendation is to treat the CSCF attestation as the first deliverable for the Swift footprint, because it has a fixed annual cycle and a visible consequence for non-compliance, then build the DORA program around it.

The two are not substitutes. DORA applies to the whole financial entity under Article 2(1), covering ICT risk management, incident reporting, resilience testing and third-party risk across every system the institution runs. The CSCF covers only the infrastructure that connects to Swift, under the architecture type that applies to your connection. A clean KYC-SA attestation therefore tells your supervisor very little about the rest of your ICT estate, and a DORA gap assessment will not establish that your Swift environment meets the CSCF. Plan separate scopes, separate owners and separate evidence sets, and expect overlap only in shared identity, logging and incident response controls.

Before committing budget, confirm two scope questions in writing. First, ask your national competent authority how it expects DORA to be evidenced for your entity type and whether any Swift-related systems fall under its ICT register or testing expectations. Second, confirm with Swift which architecture type applies to your connection and which CSCF version you attest against for the current window, since the controls in scope depend on that choice. Your answers to those two questions will decide how much of the CSCF work can be reused in DORA evidence and where the two programs must stay apart.

How scope, enforcement and proof differ between CSCF and DORA

This table compares who must comply, what each framework covers, where the obligation comes from, who checks it and what proof results. Read it to see which obligations sit on the Swift footprint, which sit across the whole financial entity, and where one set of evidence can feed the other.

Dimension	SWIFT CSCF	DORA
Who must comply	Swift users connected to the Swift network, using the architecture type that fits their connection	20 types of financial entity under Article 2(1), including credit and payment institutions, plus ICT third-party service providers in point (u)
What is in scope	Swift-related infrastructure and the controls that apply to the user's architecture type (A1, A2, A3, A4 or B)	The financial entity's ICT risk management, incident handling, resilience testing and third-party ICT risk across the whole organization
Source of obligation	Swift's Customer Security Programme, applied through the user's Swift connection and the KYC-SA attestation	Regulation (EU) 2022/2554, directly applicable in all member states, with technical standards adopted as delegated and implementing regulations
Controls or requirements	32 controls in CSCF v2026: 26 mandatory and 6 advisory, built on three objectives	Requirements across five chapters on ICT risk, incidents, testing, third parties and information sharing, detailed in technical standards
Supervisor or Swift role	Swift may report users without a valid attestation or not compliant with mandatory controls, visible to their supervisors	National competent authority per entity type under Article 46; ECB for significant credit institutions; ESAs as Lead Overseers for critical ICT providers
Form of proof	Annual attestation in KYC-SA, backed by an independent assessment that may be internal, by second or third line functions, or external	No certification scheme. Authorities supervise under Article 50. The only authority-issued attestation is for a threat-led penetration test meeting requirements (Article 26(7))
Incident reporting	Not a reporting regime under CSCF. Incident response is a control objective, so evidence sits in the controls themselves	Initial notification within 4 hours of classifying as major and no later than 24 hours after awareness, intermediate report within 72 hours, final report within one month (Delegated Regulation 2025/301, Article 5)
Testing	Independent assessment of mandatory and advisory controls each cycle, with the scope set by the architecture type	Testing programme under Chapter IV, with threat-led penetration testing that produces the Article 26(7) attestation where required
Version or cycle	CSCF v2026 is the version attested between July and December 2026, published in July 2025 with up to 18 months to prepare for changes	Applies since 17 January 2025; Commission review of DORA due by 17 January 2028 (Article 58(1))

Who must meet the CSCF, who must meet DORA, and where they overlap

The CSCF applies to every Swift user, but the controls it asks you to implement depend on how you connect. Swift's Customer Security Programme is mandatory for Swift users, who implement the controls, have them independently assessed, and attest compliance annually in the KYC-SA application. Which controls are in scope is set by your architecture type, expressed as A1, A2, A3, A4 or B. Start by confirming your architecture type against Swift's published definitions, because that choice determines the scope of your 2026 attestation before any control work begins. Your Swift footprint is also what the attestation covers, so document the components, connectors and operators that sit inside it.

DORA applies to 20 types of financial entity, and Article 2(1) lists them in points (a) to (t). The list runs from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories. If you are a credit or payment institution, DORA almost certainly reaches your whole legal entity, not only the systems you use for Swift. Article 1(2) adds a second layer: for financial entities identified as essential or important entities under NIS2, DORA is treated as the sector-specific Union act. Confirm with your national competent authority which entity type you fall under and whether you are an essential or important entity, because those answers decide which supervisory expectations and incident duties apply to you.

The Swift footprint is one ICT system inside your wider DORA ICT risk inventory, not a separate regime. Your DORA work will need an inventory of ICT assets, services and third-party dependencies, and the Swift connection, its interfaces and its service providers should appear in it with their criticality and dependencies. CSCF evidence can feed that inventory and the associated risk assessments, but it does not classify your ICT risk for you. Ask your supervisor how they expect the Swift footprint to be recorded, and agree that boundary before you decide which controls the CSCF attestation can stand in for.

Who enforces each framework and what happens when you fall short

The Customer Security Programme is mandatory for Swift users, who must implement the CSCF controls, have them independently assessed, and attest compliance each year in the KYC-SA application. Enforcement runs through Swift's attestation process rather than through a regulator's penalty regime. Swift may report users that have no valid attestation or that are not compliant with mandatory controls, and that status is visible to their supervisors, which is where the practical consequence lands.

Annual attestation: Each Swift user files its own attestation in KYC-SA every year; a lapsed attestation is a gap Swift can act on.
Reporting to Swift: Swift may report users without a valid attestation or with mandatory controls not met.
Supervisory visibility: Non-compliance is visible to the user's supervisors, which can drive questions from the regulator even though Swift itself is not a supervisor.
Mandatory versus advisory: Of the 32 CSCF v2026 controls, 26 are mandatory, so a gap on a mandatory control carries more weight than one on an advisory control.
Assessor independence: The assessment may be internal, by second or third line functions, or external, and Swift's CSP Assessor Certification is optional.

Confirm with your Swift relationship team exactly how a reported status is communicated and what steps follow, because those details shape the response plan. Check which assessor type your supervisor will accept as evidence for your jurisdiction.

Where the CSCF and DORA work overlaps, from mapping facts only

The CSCF secures the Swift footprint through an annual community attestation, while DORA governs ICT risk across the whole financial entity. The areas below are where both touch the same work, so one set of evidence may serve both. No supplied mapping shows that CSCF controls satisfy DORA articles, so treat each card as a starting point for a control-by-control check.

Access control and identities

The CSCF groups its controls under the objective to know and limit access, covering credentials, identities and privileges. DORA's ICT risk management chapter also expects access rights and identity management to be controlled across ICT systems. The CIS Controls Navigator lists DORA among its mapped frameworks, but that mapping does not show that a given CSCF control meets a given DORA article. Compare the scope of each: the CSCF applies to the Swift-connected infrastructure, while DORA applies to all ICT systems supporting critical or important functions.

Detection and anomaly response

The CSCF's detect and respond objective covers anomaly detection and incident response for the Swift environment. DORA's incident management chapter requires financial entities to detect, manage and classify ICT-related incidents. Both need monitoring that feeds a response process, but the CSCF evidence covers only Swift-related components. Ask whether your SIEM and detection coverage extend to the Swift footprint in a way that can also support DORA incident classification.

Incident reporting and timelines

DORA's incident reporting rules set deadlines that the CSCF does not. Under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it. A Swift-related incident may therefore trigger both a Swift reporting duty and a DORA notification clock. Confirm with your competent authority and Swift how each report is made and who signs it.

Third-party and Swift connectivity risk

DORA's third-party chapter requires oversight of ICT third-party service providers, including arrangements that support critical functions. The CSCF also requires you to control the environment connecting to Swift, which may include service bureaus or hosted connectivity. Map each Swift-related provider against both sets of obligations. The DORA register of information and the CSCF's scope for connected providers may describe the same relationship in different terms, so confirm the boundary with your assessor and supervisor.

Testing and assessment evidence

DORA's resilience testing chapter requires entities to run testing programmes, and only the threat-led penetration test attestation under Article 26(7) is authority-issued. The CSCF requires an independent assessment each year, which may be internal, by second or third line functions, or external. A CSCF assessment does not replace DORA testing, but its test results and control evidence may inform it. Agree in writing which tests count for which obligation before the next cycle.

Mapping limits and supervisor confirmation

ENISA states that its mapping between standards and NIS2 is not a measure of equivalence and does not assess whether a standard fully covers the regulation's requirements. NIST likewise does not check the correctness of non-NIST mappings. Treat any CIS Navigator entry for DORA as an index for your own control-by-control analysis, not as proof of compliance. Record your rationale for each mapped article and confirm the approach with your national competent authority.

How incident reporting and testing differ under DORA and the CSCF

The sharpest difference between the two regimes is the clock. Under DORA, a major ICT-related incident triggers a fixed reporting sequence set by Commission Delegated Regulation (EU) 2025/301. Under Article 5 of that delegated regulation, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after the entity became aware of it. The intermediate report follows within 72 hours of the initial notification, and the final report is due no later than one month after the latest intermediate report. An incident response team that has no pre-agreed way to classify severity, and no named owner for each notice, will spend the first hours of an event deciding who writes the notice rather than containing the problem. Confirm now who classifies an incident as major, who signs each notice, and which regulator portal and template your authority expects.

The CSCF does not carry an equivalent supplied reporting clock. Its detect and respond objective asks the Swift user to detect anomalies on its Swift environment and to respond to incidents, and the controls in that objective cover incident response planning and information sharing. Those obligations are not a regulator-facing notification sequence with hour-based deadlines. A bank that treats its CSCF incident runbook as its DORA reporting procedure will likely find gaps in the timing and content of its notices. The practical step is to keep the two runbooks linked: a Swift-related event that meets the DORA major threshold should trigger the DORA sequence in parallel with the Swift response, and the team should check whether its Swift contact and incident information sharing steps are recorded in the same timeline.

Testing is where the two regimes most often get confused. DORA's Article 26(7) provides for one authority-issued attestation in the regulation itself: a confirmation that a threat-led penetration test met the requirements. Where a financial entity is in scope for that testing, the attestation comes from the competent authority process, not from the CSCF. The CSCF independent assessment, whether performed internally by a second or third line function or externally, checks the Swift controls and produces the annual KYC-SA attestation. It does not replace a threat-led penetration test and cannot be presented as one. Ask your supervisor whether TLPT applies to your entity and, if it does, whether Swift-connected systems are in the test scope. Plan that scope with the team that owns the Swift footprint so the evidence reaches both files.

Who assesses each framework, what is issued and on what cycle

This table compares who checks each regime, what document or decision it produces, how often it recurs and who sees the result. Read it to see that the CSCF produces an annual attestation filed through KYC-SA, while DORA produces no certificate and relies on supervisory powers and reporting duties.

Element	SWIFT CSCF	DORA
Assessor	Internal second or third line function, or an external assessor, under Swift's independent assessment rules	National competent authority for each financial entity type, with the ECB for significant credit institutions and the ESAs for critical ICT third-party providers
Output	Annual attestation submitted in the KYC-SA application	No certificate or attestation of compliance; supervisors use inspection and information powers
Authority-issued attestation	Not applicable; Swift may report users without a valid attestation	Only the Article 26(7) attestation that a threat-led penetration test met requirements
Assessor credential	Swift CSP Assessor Certification is optional	DORA sets no assessor certification scheme
Publication and cycle	New CSCF version published each July, applying a year later, with up to 18 months to prepare	Applies since 17 January 2025; Commission review report due by 17 January 2028 under Article 58(1)
Who sees the result	Swift, and the user's supervisors can see non-compliance	Competent authorities supervise; reporting of major incidents goes to the authorities
What to confirm with your supervisor	Whether your internal assessor's independence meets your own governance model	Which authority supervises your entity and how it expects ICT risk evidence to be packaged

Doing both: the order that avoids duplicate evidence

This sequence starts with DORA scope and the asset inventory, then runs the CSCF assessment so its results feed DORA ICT risk, incident and testing work without producing two unrelated evidence sets. Each step names the output that tells you it is finished.

Confirm DORA entity scope and ICT asset inventory
Start by confirming which legal entities in your group fall under DORA by checking the financial entity types in Article 2(1), and whether any entity is classed as significant or relies on critical ICT third-party providers. Your compliance and legal teams own this decision, and the national competent authority for each entity is the body to confirm it with. Build or refresh one ICT asset inventory that covers systems in DORA scope, including Swift-connected components. The step is done when a signed scope statement and an inventory with named owners exist, because every later step draws on both.
Map the Swift footprint and architecture type
Identify every Swift connection, interface, and operator system that sits inside the inventory from the previous step, and record how each one connects to Swift. Use the five architecture types (A1, A2, A3, A4 and B) to determine which CSCF controls apply to each connection, and confirm the classification with your Swift security lead or the Swift Customer Security Programme documentation. The output is a footprint register that lists each component, its architecture type, its owner, and the controls in scope. The step is complete when the register has been reviewed by IT operations and by the business owner of the payment flows.
Run the CSCF independent assessment against the current version
Assess the mapped footprint against CSCF v2026, which Swift users attest against between July and December 2026. The assessment can be internal, by a second or third line function such as risk, compliance or internal audit, or external, and the choice of assessor is yours to make. Test the 26 mandatory and 6 advisory controls, keep the evidence for each control tied to a footprint component, and record the results in the assessment report. The step is done when the assessment report is signed off and the KYC-SA attestation decision is recorded, including any gaps and remediation owners.
Feed CSCF results into DORA ICT risk management
Take the CSCF assessment results and map them into your DORA ICT risk management framework, so that the same findings inform the risk register, the ICT risk assessment for each in-scope system, and the controls review. Explain to the risk committee which CSCF findings also count as DORA ICT risk findings, and which remain Swift-specific. The output is an updated ICT risk register where each Swift-related risk points back to its CSCF control reference. The step is complete when the risk owner has accepted the mapping and the gaps have been logged for treatment.
Connect CSCF detection and response to DORA incident processes
Link the CSCF detect and respond controls, including anomaly detection and incident response, to the ICT-related incident management process that DORA requires under Chapter III. Confirm which Swift-related incidents must be classified and reported under the incident reporting timelines in Delegated Regulation (EU) 2025/301, and make sure your runbooks name both the Swift escalation path and the DORA reporting path. The output is a combined runbook set with clear decision points. The step is done when the incident team has walked through at least one scenario with the runbooks and the compliance lead has confirmed the reporting obligations.
Check each reuse against supervisor expectations
Before relying on any shared evidence, such as the asset inventory, access records, and incident runbooks, confirm with your national competent authority or your DORA compliance lead how they expect that evidence to be presented and whether a CSCF assessment is acceptable as input to DORA work. DORA sets no certification scheme, so the supervisor decides what is sufficient, and Swift's attestation does not replace DORA supervision. Record each reuse decision in a short register that names the evidence, the DORA article it supports, and the supervisor's stated position. The step is complete when the register is approved by the compliance function.
Plan TLPT and third-party work using the shared inventory
Use the same asset inventory and footprint register to scope any threat-led penetration testing required under DORA and to plan ICT third-party risk work, including contracts and oversight of providers that support the Swift footprint. Confirm with your competent authority whether TLPT is required for your entity, since that determination sits with the authority, and check whether any attestation under Article 26(7) would apply. The output is a testing and third-party plan that references the shared inventory and the CSCF findings. The step is done when the plan has been reviewed by the risk, security, and procurement leads and approved by senior management.

Questions EU banks ask before hiring help on CSCF and DORA

Does passing the SWIFT CSCF attestation satisfy DORA?

No. The CSCF attestation secures your Swift footprint and is filed with Swift, while DORA covers ICT risk across the whole financial entity and is supervised by your national competent authority. CSCF evidence can feed several DORA workstreams, such as access control and logging evidence for ICT risk management, but it does not replace the ICT risk framework, incident classification and reporting under Chapter III, or the testing program under Chapter IV. Confirm with your supervisor how they expect the two evidence sets to be presented.

What drives the cost of CSCF and DORA help?

No fixed price applies to either. Cost is driven by scope, meaning how many Swift interfaces and connected systems are in play, the architecture type that determines which controls apply (A1, A2, A3, A4 or B), how much usable evidence already exists, and who performs the independent assessment, whether internal staff, an external assessor, or both. Swift's CSP Assessor Certification is optional, so ask whether the assessor holds it. Recurring costs include annual attestation work and reassessment. Ask every bidder for a written, fixed-scope quote that itemizes these drivers.

How long does CSCF preparation take against the attestation window?

Swift publishes a new CSCF version every July, a year before it applies, and gives users up to 18 months to prepare for new or changed controls. The current version, CSCF v2026, is the one attested against between July and December 2026. Work backward from your December attestation deadline, and check the Swift Customer Security Programme pages for the exact dates of the next version. Your own duration depends on your starting evidence and scope, so ask a provider to state the expected timeline in the written scope.

What does the work need from our internal staff?

Expect internal time from security, operations, the Swift administrators and the teams that own identity, privileged access and logging. Staff must confirm how each Swift interface connects, provide configuration and access records, and explain operational processes. Independent assessment may be done by a second or third line function such as risk, compliance or internal audit, so those teams also need capacity. Ask a provider to list the named roles and the hours it expects from each, and confirm who signs off the final evidence.

Can our bank prepare for CSCF and DORA without outside help?

Yes, if you have people who understand both regimes, the Swift architecture and the ability to perform an independent assessment that meets the requirements. The CSCF permits internal assessment by a second or third line function, so an experienced internal team can do the work. Outside help is most useful where the team lacks the time, the Swift architecture knowledge, or an independent view on the evidence. Weigh the cost of staff time and the risk of a gap found by your supervisor against the cost of external support.

What should we ask for in a fixed-scope written quote?

Ask for a written scope that names the architecture type for each Swift interface, the CSCF version and controls covered, and the list of mandatory and advisory controls to be assessed. Require deliverables to be listed, such as gap findings, remediation support, evidence packs and the DORA mapping. Ask who performs the independent assessment and whether they hold the optional CSP Assessor Certification, what is excluded, how changes in scope are priced, and what ongoing support is offered after attestation. DeployOpen scopes most engagements as fixed-scope projects agreed in writing before work starts.

Which DORA obligations sit outside what the CSCF covers?

The CSCF covers the controls for your Swift footprint, while DORA reaches the whole financial entity. Areas that typically need separate work include the ICT risk management framework, major incident classification and reporting, digital operational resilience testing, and third-party ICT risk management. Incident reporting under Delegated Regulation (EU) 2025/301 sets an initial notification within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it. Confirm these obligations with your national competent authority, as the CSCF does not supply them.

What the CSCF leaves to DORA and what DORA leaves to the CSCF

The CSCF covers only the Swift footprint, so an institution that treats a clean attestation as proof of DORA readiness will have gaps. The CSCF does not cover the whole ICT estate, third-party contract terms or entity-wide governance, all of which DORA addresses under its ICT risk management, third-party risk and governance requirements. Before planning, map each DORA ICT risk obligation to the systems the CSCF scopes in. Anything outside that boundary, such as core banking, customer channels, data platforms and the cloud services that host them, needs its own evidence under DORA. Check also whether the CSCF scope for your architecture type reaches the ICT third parties that run any Swift-connected component, and whether the contracts with those providers contain the terms DORA expects.

DORA does not define the Swift-specific control set, the architecture types or the annual KYC-SA attestation. Those come from Swift. The CSCF controls, grouped under its three objectives, are the only place where the Swift-specific control set and the five architecture types (A1, A2, A3, A4 and B) are set out, so the scope decision for your connection type must be taken from the current CSCF version, not from DORA text. The attestation is filed in the KYC-SA application and is visible to supervisors, which is a Swift process rather than a DORA certificate. Confirm with your Swift administrators which architecture type applies to each connection, and keep that decision in the same record as your DORA asset inventory so auditors can trace one to the other.

Note that the Digital Omnibus proposal, COM(2025) 837 (procedure 2025/0360(COD)), may change some DORA obligations. It is a proposal, not settled law, so confirm its current status in the European Parliament Legislative Observatory) and with your national competent authority before fixing incident reporting, testing or register planning. Also check how the CSCF version that applies to you interacts with any changed DORA duties, because the CSCF is revised on its own annual cycle.

How DeployOpen scopes and delivers CSCF and DORA readiness

DeployOpen works on the Swift footprint and the wider DORA ICT risk picture as two scoped pieces of work, with the boundary agreed in writing before any build starts. We plan, implement, document and hand over the controls and evidence, while the independent assessment and any supervisory conversations stay with your assessor and your competent authority.

How we scope

Written scope fixes which Swift architecture type applies and which CSCF v2026 controls are in play.
The scope names the Swift-connected systems, administrators, and hosting environments covered by the work.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

We implement and harden the mandatory and advisory controls in your own infrastructure, cloud accounts, or data centers.
Security testing of Swift-adjacent applications and infrastructure is scoped separately and documented as evidence.
ICT risk, incident and testing records are structured so the same evidence can be read against DORA articles.

How we hand over

You receive documentation of configurations, control implementation, and the evidence trail for each in-scope control.
Deliverables are mapped to the CSCF control set and to the DORA ICT risk areas named in the agreed scope.
Confirm with your independent assessor and compliance lead which artifacts they will accept before handover.

How we support

Ongoing support, upgrades, and continuous testing are available as retainers after the initial scope closes.
Retainers can cover annual CSCF version changes, which Swift publishes each July, and DORA-related updates.
Ask any provider to confirm in writing who holds attestation sign-off, since DeployOpen prepares evidence but does not issue certifications.