Every organization on the SWIFT network has to attest, each year, that its SWIFT-related infrastructure meets SWIFT's Customer Security Controls Framework — and that attestation now has to be backed by an independent assessment. Intect performs that independent assessment and the readiness work behind it: we scope to your architecture type, test the controls rather than just reading them, and get your KYC-SA attestation onto solid, defensible ground.
Independent CSCF assessment to attestation-ready. CERT-In Empaneled. We test the controls we assess.
SWIFT's Customer Security Programme is the community-wide effort to harden financial messaging against attack and fraud; the CSCF is how its first pillar becomes real controls.
SWIFT's Customer Security Programme (CSP) is the global, community-wide effort to harden the financial-messaging ecosystem against cyber-attack and fraud. It rests on three pillars: secure and protect your own SWIFT environment, prevent and detect fraud in your counterparty relationships, and share information so the whole community can prepare for the next attack. The first of those pillars is operationalized through the Customer Security Controls Framework (CSCF) — the set of security controls that every SWIFT user is expected to implement on the infrastructure they use to connect to SWIFT.
The CSCF is not a static document. SWIFT revises it annually — publishing the next version each July, a year ahead of when it takes effect — so the controls keep pace with how attackers operate. Each year, every SWIFT user must complete a self-attestation through KYC-SA (Know Your Customer – Security Attestation), declaring its level of compliance against the version of the CSCF that applies to that cycle. And since 2021, that attestation can no longer be a self-declaration on trust alone: it must be supported by an independent assessment of the controls. That independent assessment is the work this page is about — and getting it right is what turns your attestation from a claim into evidence your counterparties and correspondents can rely on.
"An attestation you sign is a claim. An attestation we have independently assessed — and tested — is assurance your correspondents can bank on."
The obligation is broad: every SWIFT user attests, every year. What differs from one organization to the next is which controls apply — and that is decided by your architecture type, the way your SWIFT-related components are deployed. Establishing that type correctly is the first and most consequential step of any assessment, because it defines the control set you will be measured against. We determine it precisely before anything else.
Correspondent banks, commercial and regional banks and other financial institutions sending and receiving SWIFT messages. Indian banks carry this alongside their RBI cyber-security obligations.
Operators, clearing and settlement systems and other market infrastructures connected to the network.
Corporates running their own SWIFT connectivity for treasury and payments, including via Alliance Lite2.
Organizations that connect through, or provide, shared SWIFT infrastructure — where scoping the right components matters most.
We confirm your type at scoping; users on Architecture type B are not required to comply with the controls that apply only to types A1–A4, so getting this right keeps the assessment proportionate.
Whatever your category, the assessment measures the same families of control — calibrated to the architecture type that actually describes your environment, never more and never less.
Every control in the CSCF rolls up to one of three overarching objectives, broken down into security principles and then into individual controls.
Mandatory controls form the security baseline that the whole community must meet — they are what your independent assessment and attestation are graded against. Advisory controls are recommended good practice that SWIFT may make mandatory in a future annual revision as the threat landscape shifts — so treating them as a roadmap, not an afterthought, is the smart posture. (In the current cycle, controls that were advisory are being promoted to mandatory — which is exactly why architecture-type scoping and forward-looking remediation matter.)
Secure Your Environment — Restrict and protect the SWIFT-related infrastructure: a defined secure zone, hardened and segregated systems, control over the components that touch the network, and a managed flow of data in and out of the environment.
Know and Limit Access — Make sure only the right people and systems can reach the SWIFT environment: strong identity and access management, multi-factor authentication, least-privilege, and tight control of privileged and operator access.
Detect and Respond — Be able to see an attack and act on it: logging and monitoring of the SWIFT environment, integrity checking, anomaly detection, and a tested incident-response capability.
One framework, revised every year. The control IDs are organized under these three objectives; the exact count of mandatory versus advisory controls is set by the version of the CSCF in force for the attestation cycle — we always assess you against the current version that applies to you.
A disciplined, evidence-led path from architecture-type scoping to an attestation you can stand behind — built so your team always knows where the assessment stands and what to act on next.
FIG. 02 — Independent CSCF assessment lifecycle · 01–07 · node 04 is VAPT-backed technical validation
Our coverage maps to the applicable CSCF controls under all three objectives, calibrated to your architecture type. Across an engagement we systematically work through the following:
Scope & architecture-type determination
Component inventory across SWIFT interfaces, connectors, operator endpoints, jump servers and supporting infrastructure; confirmation of architecture type and the resulting applicable control set.
Control mapping & evidence planning
Mapping each applicable mandatory and relevant advisory control to systems, owners and the evidence required; an evidence-readiness check before formal assessment so nothing stalls mid-engagement.
Secure Your Environment
Assessment of the secure-zone definition, system hardening and segregation, control of internal data flows and back-office connectivity, and protection of the components that touch the network.
Know and Limit Access
Assessment of identity and access management, multi-factor authentication, least-privilege and segregation of duties, and the control of privileged and operator access.
Detect and Respond
Assessment of logging and monitoring of the SWIFT environment, integrity checking, anomaly detection, and incident-response readiness.
Technical validation (the offensive edge)
Vulnerability assessment and targeted penetration testing around the secure zone and its access paths, to evidence whether the access and detection controls actually hold.
Reporting & attestation support
The independent assessment finding per control, a prioritized remediation roadmap, and hands-on support translating results into an accurate KYC-SA attestation.
A document-only assessment confirms that a control is described. An attacker doesn't care whether it's described — only whether it stops them. We close that gap, exactly where the CSCF cares most: access, and detect-and-respond.
A purely documentary CSCF assessment reviews policies, samples configurations and interviews owners to confirm that each control is in place on paper. It is necessary work — and it is where most assessments stop. The trouble is that a written access policy and an access control that actually resists abuse are not the same thing, and the difference is precisely what an attacker who is after your SWIFT environment will look for.
Intect comes from offensive security. So where it matters most — your "Know and Limit Access" and "Detect and Respond" controls — we validate by testing: vulnerability assessment and targeted penetration testing around the secure zone and its boundaries that turn "we have MFA and monitoring" into demonstrated evidence of what an unauthorized actor can and cannot reach, and whether you would actually see them. You get an assessment backed by proof of real exposure — and an attestation your correspondents and your Board can trust because it has been earned.
We are CERT-In Empaneled, so the assurance is independent and credible — and we come from offensive security, so it is technically validated. For a framework built around access and detection, that combination is the point.
VAPT-BACKED CONTROL VALIDATIONEvery engagement ends in an independent assessment your team can act on and your leadership can stand behind — written for the engineers who will remediate and the people accountable for the attestation.
Independent CSCF assessment report
An independent assessment finding for each in-scope control, mapped to the applicable CSCF objective and architecture type, with evidence and a clear compliant / non-compliant determination.
Architecture-type & scope record
Documented architecture-type determination and component inventory, so the basis of the assessment is transparent and re-usable next cycle.
Technical validation evidence (the offensive edge)
VAPT findings around the access and Detect-and-Respond controls, with reproducible proof-of-concept and demonstrated impact, so control failures are evidenced, not asserted.
Gap analysis & remediation roadmap
Prioritized, specific remediation guidance with clear ownership and sequencing, including forward-looking attention to advisory controls slated to become mandatory.
KYC-SA attestation-readiness support
Support translating assessed results into an accurate, complete KYC-SA submission, and re-verification of remediated controls so closure is evidenced.
Direct assessor access
A debrief with the people who performed the assessment, not a handoff to a call centre.
CERT-In Empaneled — A real, recognized credential — so the independent assessment, and the technical validation behind it, carries weight where it counts.
Offensive heritage — We come from penetration testing and red teaming. We assess access and detection controls by testing them, surfacing the exposure a paper review misses.
Researcher-led, not checklist-led — Engagements are run by practitioners who understand both the CSCF and the adversary — so findings are accurate, contextual and defensible.
India-based & regulator-fluent — A Delhi-based team that already speaks the language of RBI cyber-security supervision, so for Indian banks the SWIFT and RBI assurance can move in step.
No — and we will not imply otherwise. SWIFT requires every user’s attestation to be supported by an independent assessment, performed either by an internal independent function (such as internal audit) or by an external party with the right competencies. Intect provides that external independent assessment. We do not claim any SWIFT accreditation, endorsement or directory listing — the credibility of our work rests on our independence, our CERT-In empanelment and the fact that we test what we assess. You — not Intect — submit the KYC-SA attestation to SWIFT.
You can, if you have a genuinely independent internal function (typically internal audit) that is separate from the people who run and maintain the SWIFT environment. Many organizations prefer an external independent assessment for objectivity, depth of testing and the comfort it gives correspondents and counterparties. Some choose a blend. We are happy to provide the external assessment, or to support and validate an internal one.
By your architecture type — A1, A2, A3, A4 or B — which describes how your SWIFT-related components are deployed. We determine it at scoping through a component inventory, because it defines the exact set of mandatory (and relevant advisory) controls you will be assessed against. Users on type B, with no local SWIFT footprint, are not required to comply with the controls that apply only to types A1–A4.
Every year. SWIFT publishes each annual CSCF version in July, a year ahead of when it takes effect, and users attest against the applicable version within the annual KYC-SA window. We time the assessment so your attestation is ready well inside it. An independent assessment can remain valid across cycles for up to a defined period provided your environment and the mandatory controls relevant to you have not materially changed — we will tell you when a fresh assessment is genuinely needed and when it is not.
We would not. Advisory controls are SWIFT’s signal of where the baseline is heading; the framework regularly promotes advisory controls to mandatory in later annual revisions. We assess your mandatory controls for the attestation and flag the advisory controls most likely to affect you next, so remediation is a roadmap rather than an annual scramble.
We technically validate the controls the CSCF cares most about. Rather than confirming on paper that access control and monitoring exist, we test whether they hold — using vulnerability assessment and targeted penetration testing around the secure zone — so the assurance behind your attestation is backed by proof of real exposure, not a checklist of assertions.
Your SWIFT obligation rarely stands alone — especially for Indian financial institutions. These sibling assessments share the same evidence and the same team.
Tell us your architecture type — or let us help you determine it — and where you are in your KYC-SA cycle, and we'll scope an independent CSCF assessment that fits, or connect you directly with an assessor.