July 13, 2026
Updated: July 13, 2026
A practical guide to CSCF v2026 Control 7.3A status, scope, cadence, evidence, remediation, retesting, and assessment boundaries.
Mohammed Khalil
Framework verified: 13 July 2026 — CSCF v2026
Swift’s Customer Security Programme (CSP) is mandatory for Swift users, but that does not make every control in the Customer Security Controls Framework (CSCF) mandatory. In the public CSCF v2026, Control 7.3A, “Penetration Testing,” is an advisory control for architecture types A1, A2, A3, A4 and B. A properly authorised Swift-focused penetration test can validate attack paths, segmentation, access controls and other technical weaknesses affecting Swift-related infrastructure. It does not replace Control 2.7 vulnerability scanning, the annual independent assessment or the KYC Security Attestation (KYC-SA) submission. Scope must follow the user’s architecture, ownership boundaries, connectivity, material changes and risk. The public control does not create a universal annual penetration-test obligation.
Swift describes CSP as a mandatory initiative for reinforcing the security of each user’s Swift-related environment. The CSCF translates that programme into product-agnostic controls organised around three objectives: secure the environment; know and limit access; and detect and respond.
Mandatory controls establish the community security baseline; advisory controls are recommended good practice. Applicability depends on architecture and the components forming the user’s Swift footprint. The user identifies applicable controls, implements them, obtains an independent assessment and submits its annual KYC-SA security attestation.
Swift states that the independent assessment must validate, at minimum, the applicable mandatory controls. It can be performed by an appropriately independent internal function, an external assessor, or a qualifying mixed team. This distinction matters because a penetration test examines selected technical attack paths; an independent assessment evaluates whether applicable controls are designed and implemented as declared.
Not as a universal Control 7.3A requirement in CSCF v2026. CSP itself is mandatory, while the framework assigns different statuses to its controls. The current CSCF v2026 document labels 7.3A as advisory across A1, A2, A3, A4 and B.
| Item | Current v2026 status | What it requires | What it does not mean |
|---|---|---|---|
| Swift CSP programme | Mandatory initiative | Follow the CSP process for the user’s Swift footprint | Every CSCF control is mandatory |
| Applicable mandatory CSCF controls | Mandatory by architecture/applicability | Implement and attest applicable mandatory controls | One technical test proves all controls |
| Control 2.7 Vulnerability Scanning | Mandatory for A1–A4; advisory for B | Regular scanning for known OS- and application-level vulnerabilities; at least annually or after significant change in the public guidance | A scan is a penetration test |
| Control 7.3A Penetration Testing | Advisory for A1–A4 and B | Risk-based penetration testing of relevant Swift-related components, with documented results and remediation input | Every user must buy an annual pentest |
| Independent assessment | Required to support the yearly declaration | Independently assess design and implementation of at least applicable mandatory controls | The pentest provider alone decides CSCF compliance |
| Annual KYC-SA attestation | Annual | Declare compliance status for applicable controls through KYC-SA | Attestation cadence automatically dictates pentest cadence |
As with penetration testing for compliance generally, a mandatory programme can contain an advisory testing method. An institution may still test annually because of regulation, material change, counterparties, risk or policy; that is not automatically a Swift 7.3A mandate.
The public v2026 control sharpens guidance on scope, perspective, cadence and evidence. It calls for risk-based scoping, allows the method and attack origin to vary, and expects testing to adapt to change. Testing must minimise availability or integrity risk, use staff independent of the infrastructure team, and be documented for remediation.
The public text in CSCF v2026 Control 7.3A (pages 95–96) provides four important timing signals:
What the public control does not provide is a named list of three official scenarios that must be allocated across a three-year cycle. It refers users to Swift CSP FAQ KB 5021823 for additional scoping and testing-scenario detail. Some current third-party pages describe a three-scenario, three-year model, but those labels should not be presented as Swift’s wording until the KB article is checked. Do not repeat an unsupported scenario list as Swift guidance.
As of 13 July 2026, Swift’s public CSP document centre still identifies v2026 as the latest CSCF, while Swift’s own webinar material refers to “v2027 readiness.” Recheck the CSP document centre before publication or any later refresh.
| Activity | Main purpose | Typical method | Output | CSCF relationship | Can it replace the others? |
|---|---|---|---|---|---|
| Vulnerability scanning | Find known weaknesses broadly | Credentialed or uncredentialed automated scanning with review | Vulnerability list, severity and remediation status | Control 2.7; mandatory for A1–A4 and advisory for B | No |
| Penetration testing | Validate exploitability, attack paths and control effectiveness | Authorised, goal-based manual and tool-assisted testing | Narrative of tested paths, findings, evidence and remediation guidance | Control 7.3A; advisory in v2026 | No |
| Independent control assessment | Evaluate control design and implementation | Evidence review, interviews, observation and sampling | Assessment conclusions against applicable CSCF controls | Required to support the annual attestation | No |
| Security attestation | Declare the user’s compliance status | KYC-SA submission based on assessed status | Published security attestation | Annual CSP step | No |
| Remediation retest | Verify a claimed fix | Targeted re-examination of the issue and affected path | Closure, partial closure or residual-risk evidence | Supports evidence maintenance; not a substitute for original testing | No |
In practical terms, scanning asks, “Which known weaknesses may exist?” Penetration testing asks, “Can an authorised tester turn weaknesses or control gaps into a meaningful path?” Assessment asks, “Are the applicable controls designed and implemented as declared?” Attestation records the organisation’s declared status. For more detail, see why vulnerability assessments and penetration tests serve different purposes.
There is no universal asset list. Start with the architecture, Swift-related components, data flows, operator paths and provider boundaries. CSCF v2026 identifies jump servers, dedicated operator PCs, the data-exchange layer, Swift-related hosts and access, protective network devices, and relevant remote virtualisation or cloud access as possible in-scope components.
| Scope area | Why it may matter | Example validation objective | Evidence produced | Applicability caveat |
|---|---|---|---|---|
| Secure-zone boundary | Defines a critical trust boundary | Validate segmentation and authorised paths | Tested paths, boundary findings, rule observations | Architecture dependent |
| Back-office first-hop systems and data flows | May provide a path toward the secure zone | Assess whether approved flows can be abused or bypassed | Flow coverage and attack-path evidence | Include only relevant flows |
| Messaging/communication interface and GUI | Hosts or exposes Swift-related functions | Assess access controls and configuration safely | Component coverage and findings | Swift-specific product testing must follow Swift policy |
| Customer connectors or middleware | Bridges systems and trust zones | Validate authentication, authorisation and isolation | Connector-path evidence | Ownership and architecture vary |
| Operator PCs and jump servers | Concentrate privileged or operational access | Assess role separation, access controls and hardening | Role/path coverage and observations | Dedicated and general-purpose systems differ |
| Identity, MFA and privileged access | Controls entry to critical components | Validate approved identity and privilege boundaries | Account-role matrix and findings | Use approved test accounts only |
| Network and security devices | Protect the zone and connectors | Assess rule design and segmentation effectiveness | Configuration/test evidence | Avoid disruptive techniques |
| Virtualisation or cloud management | May control Swift-related VMs | Assess management-plane and remote-access boundaries | Authorised management-path evidence | Provider policy and written permission apply |
| Logging and detection | Supports investigation and response | Confirm agreed test events are visible and escalated | Detection timestamps and control observations | Not every pentest includes SOC validation |
| Disaster recovery | May reproduce sensitive components and pathways | Validate equivalent boundaries where applicable | DR scope and findings | Include only if active or materially relevant |
| Service bureau/provider connection | Creates a shared-responsibility boundary | Test customer-controlled connection points | Boundary and responsibility evidence | Do not test provider assets without permission |
| Participating web/API components | May introduce application-layer exposure | Validate authentication, authorisation and logic | Application findings and coverage | Only where part of the Swift-related flow |
Record asset owners, environment status, shared responsibility, test accounts, blackout windows, safety limits, third-party approvals, escalation, data handling and retest boundaries. A public-IP scan cannot show whether an internal or operator path reaches a protected Swift component.
The safe planning model is built from the public control’s verified timing statements, not from an unsourced “three-year scenario” chart.
| Planning point | Verified public guidance | Practical planning action | Evidence to retain | Trigger for earlier testing |
|---|---|---|---|---|
| Initial baseline | Use a risk-based scope covering relevant components and attack origins | Establish architecture, trust boundaries, objectives and test method | Approved scope, diagrams, rules of engagement, report | New deployment or weak evidence |
| Periodic test | At least every two years, aligned with local regulation | Select the highest-risk paths not recently validated | Coverage record, findings and remediation plan | Significant server, OS, virtualisation or network change |
| Interim evidence | Previous testing may contribute if still recent; the control notes use not older than three years | Map prior tests to current components and identify gaps | Test dates, unchanged-scope rationale and assessor review | Scope drift or evidence no longer representative |
| Comprehensive coverage | All in-scope components expected every four years, building on interim tests | Confirm no relevant component or path remains untested | Multi-engagement coverage matrix and closure status | Threat change, repeated findings or architecture change |
| Remediation and retest | Results feed security updates and remediation | Retest the issue and affected path; record residual risk | Retest evidence, tickets, approvals and closure | Failed fix or compensating-control change |
This model is not rigid. A material change can invalidate prior evidence or bring testing forward. The annual independent assessment may consider technical evidence from the current or prior cycle only if the assessor accepts its relevance and freshness. Assessment cadence and technical-testing cadence should therefore be coordinated without being conflated.
An effective scope begins with the assurance question, not with an IP count. The buyer and provider should agree:
NIST defines rules of engagement as the constraints and authority established before testing. A documented penetration testing methodology should translate those rules into a controlled workflow. Do not assume that a signed statement of work alone authorises testing of every connected provider or shared platform.
| Approach | When it may add value | Primary question answered |
|---|---|---|
| External infrastructure testing | Internet-reachable customer-controlled assets exist | What can an unauthorised external party reach? |
| Internal network testing | Internal compromise or insider paths are relevant | Can a lower-trust internal position cross into the Swift boundary? |
| Segmentation validation | Secure-zone isolation is a key control | Do intended boundaries block unauthorised paths? |
| Authenticated or grey-box testing | Roles and approved credentials are available | Can a valid user exceed intended privilege or access? |
| Application-layer testing | Web, API, middleware or GUI components participate in the flow | Do application controls prevent unauthorised actions? |
| Operator-workstation and identity-path assessment | Operator or administrative access is material | Can identity or workstation weaknesses undermine protected components? |
| Cloud/virtualisation testing | Swift-related systems use a shared platform | Are customer-controlled management and isolation controls effective? |
| Detection validation | SOC evidence is an agreed objective | Are agreed test events logged, correlated and escalated? |
| Remediation retesting | Findings have been addressed | Is the specific weakness closed, and is the affected path still viable? |
Choose internal and external penetration testing perspectives by threat path. Swift does not mandate every approach for every architecture.
Outsourcing can change who operates a control, but it does not automatically remove the Swift user’s CSP responsibilities. Document which components and controls are operated by the user, service bureau, cloud provider or another third party; then identify the evidence each party must supply.
The penetration-test scope should focus on assets the buyer owns or is authorised to test, plus explicitly approved connection points. Provider assurance reports, contractual controls, architecture diagrams and technical evidence can support the independent assessment, but they are not blanket permission to test shared infrastructure. Where cloud-hosted components are relevant, engage a provider that understands both the applicable cloud testing policy and cloud penetration testing boundaries.
The independent assessor, not the pentest provider, determines whether outsourced-service evidence is sufficient for the applicable controls. Gaps may require clarification, additional evidence, a customer-controlled test or remediation—not unauthorised testing of the provider.
| Evidence item | Owner | Why it matters | Freshness expectation | Common weakness |
|---|---|---|---|---|
| Approved scope and asset list | Swift user / asset owners | Shows what was authorised and covered | Current for the engagement | Stale inventory |
| Architecture and data-flow diagrams | Architecture team | Connects assets to trust boundaries | Reflects current footprint | Missing provider or back-office paths |
| Rules of engagement | Buyer and provider | Establishes authority and safety limits | Approved before testing | Vague third-party authority |
| Test dates and methodology | Provider | Shows when and how work occurred | Sufficient for the assessor’s cycle | Generic methodology statement |
| Tester qualifications and independence | Provider / user | Supports competence and separation | Current engagement team | Confusing tester skill with assessor authority |
| Asset, perspective and path coverage | Provider | Shows what the test actually addressed | Mapped to current scope | “Network tested” with no coverage detail |
| Findings and risk ratings | Provider | Records technical weaknesses and impact | Final report version | Unsupported severity |
| Remediation tickets and exceptions | Control owners | Shows treatment decisions | Current status | Closed ticket without technical evidence |
| Retest results | Provider | Validates claimed remediation | After the fix | Retesting only the symptom |
| Management review and residual risk | Management / risk | Records accountability for open risk | Current approval | Informal acceptance |
| Mapping to relevant CSCF objectives | Provider and assessment team | Helps evidence review without claiming compliance | Version-specific | Mapping every finding to “compliance” generically |
A well-structured penetration testing report makes coverage, limitations, evidence and remediation easier to evaluate. It should not state that the organisation “passed SWIFT” unless the statement is part of a separate, authorised assessment conclusion and is accurately described.
Assign each finding an owner, deadline and treatment decision. Prioritise by plausible impact and attack path, not scanner severity alone. Fix root causes where possible; if a compensating control or exception is used, document why, who approved it, its duration and the residual risk.
Retesting should verify the specific weakness and any affected attack path. A configuration change that closes one entry point may leave an equivalent path elsewhere. The retest record should state what was re-examined, the result, any limitations and whether further action remains. Update the evidence pack and coverage matrix rather than issuing a context-free “clean certificate.”
Use a buyer checklist that tests delivery capability and role clarity:
Swift's official independent-assessment guidance says assessor certification is optional and permits qualifying certified or non-certified internal and external assessors. That concerns the independent assessment role; every technical tester need not be a Swift CSP Certified Assessor. Conversely, a technical certification alone does not establish competence for the entire CSP assessment.
| Readiness item | Complete? | Evidence or owner |
|---|---|---|
| Current CSCF version confirmed | ☐ | Framework owner |
| Architecture type confirmed | ☐ | Swift architecture team |
| Applicable controls identified | ☐ | Compliance / assessor |
| 7.3A advisory status verified | ☐ | CSCF v2026 pages 95–96 |
| KB 5021823 scenario guidance checked | ☐ | Authorised Swift user / assessor |
| Asset inventory complete | ☐ | Asset owners |
| Trust boundaries documented | ☐ | Architecture / network teams |
| Third-party approvals obtained | ☐ | Procurement / legal / providers |
| Rules of engagement approved | ☐ | Buyer and test provider |
| Safety controls agreed | ☐ | Operations / incident response |
| Assessment and pentest roles separated | ☐ | Assurance lead |
| Evidence requirements agreed | ☐ | Independent assessor |
| Remediation owners assigned | ☐ | Control owners |
| Retest process agreed | ☐ | Provider and control owners |
DeepStrike can support authorised penetration testing of relevant network, cloud, web, API and supporting assets when they are included in an approved Swift-related scope. The engagement can provide technical findings, remediation guidance and retesting evidence. A separate appropriately independent CSP assessor may still be required to reach assessment conclusions. Testing does not guarantee compliance, KYC-SA acceptance, fraud prevention or breach prevention. Learn more about DeepStrike’s penetration testing services.
Swift CSP is mandatory, but Control 7.3A is advisory for A1, A2, A3, A4 and B in the public CSCF v2026. That means it is recommended rather than a universal mandatory control. Another obligation—such as local regulation, internal policy or a counterparty requirement—may still make testing necessary for a particular institution. Always separate the framework’s control status from the organisation’s wider obligations.
Control 7.3A is the advisory penetration-testing control. Its objective is to validate operational security configuration, identify security gaps through regular penetration testing and act on the results. Its scope may include Swift-related systems, operator PCs, jump servers, boundary devices, connectors and relevant virtualisation or cloud access. The exact scope is determined by architecture and risk, not by a universal checklist.
Not automatically. Swift requires the yearly independent assessment and KYC-SA attestation process, but the public 7.3A guidance calls for penetration testing at least every two years and after significant changes, with comprehensive in-scope coverage every four years. An institution may choose annual testing for other reasons, but it should not describe that cadence as a universal v2026 requirement unless another applicable source creates it.
Control 2.7 focuses on regular vulnerability scanning for known weaknesses. In v2026 it is mandatory for A1–A4 and advisory for B, with public guidance calling for scanning at least annually or after significant change. Control 7.3A uses penetration testing to validate security gaps and attack paths. Scanning provides breadth; penetration testing provides deeper validation. Neither replaces the other.
No. A penetration test produces technical evidence about an agreed scope. The independent assessment evaluates the design and implementation of applicable CSCF controls and supports the organisation’s yearly attestation. The assessor may use the pentest report, remediation records and retest evidence, but also needs governance, process, configuration and other control evidence. The assessor decides whether the evidence is sufficient.
Begin with the architecture type, component inventory and trust boundaries. Relevant areas may include the secure-zone boundary, data flows, jump servers, operator PCs, Swift-related hosts, connectors, network devices, identity paths, cloud or virtualisation management and customer-controlled service-bureau connections. Include only assets that are relevant and authorised, and document exclusions, safety limits and third-party permissions.
It creates a shared-responsibility and evidence boundary. The user should document which controls and components it operates and which are operated by the bureau. Testing may cover customer-controlled components and authorised connection points, while provider reports and other assurance evidence support the assessment of outsourced elements. A pentest provider must not test the bureau’s shared infrastructure without explicit written permission.
The public 7.3A guidance expects testing by expert staff independent of the team responsible for the Swift infrastructure, such as an internal red team or external provider. Whether an internal team is sufficiently skilled and independent depends on its role and reporting lines. Keep this technical independence question separate from the eligibility rules for the CSP independent assessor.
Retain the approved scope, current diagrams, rules of engagement, test dates, tester competence and independence information, coverage, findings, risk ratings, remediation tickets, exceptions, retest results, closure status and management review. Map evidence to relevant CSCF objectives without claiming that the pentest itself decides compliance. Ask the independent assessor what evidence and freshness it will accept.
As of 13 July 2026, Swift’s public document centre still identifies v2026 as the latest framework, and Swift material discusses v2027 readiness rather than a published current framework. Monitor the document centre, then compare the final 7.3A status, scope, cadence and applicability before changing this article or the test plan. Do not update only the version number.
The central distinction is simple: Swift CSP is mandatory, while Control 7.3A is advisory in the public CSCF v2026. A useful Swift-focused penetration test is architecture-aware, risk-based, authorised and documented. It complements vulnerability scanning and contributes evidence for remediation, retesting and independent assessment; it does not replace assessment or attestation.
Build the scope around real trust boundaries and ownership, use the verified v2026 cadence as the baseline, and confirm any additional scenario detail directly in Swift KB 5021823. If you need technical testing within an approved Swift-related scope, DeepStrike can help define and execute the engagement without presenting the result as a compliance guarantee.
Mohammed Khalil — Cybersecurity Architect at DeepStrike
Current DeepStrike profile lists CISSP, OSCP and OSWE. No Swift assessor status is claimed.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
