SWIFT CSP Assessment: 5 Reasons Reports Need Rework Before KYC-SA

Most SWIFT CSP rework starts before the report is written. The KYC-SA working copy says one thing, the architecture diagram shows another, and the evidence pack supports only part of the conclusion. By the time somebody notices, fieldwork that looked finished has to be reopened.

Teams sometimes describe this as a SWIFT CSP report being “rejected”. That wording is usually too blunt. The independent assessment supports the annual KYC-SA attestation, and the work may be sent back by the assessor, the institution's own quality review, or during final attestation preparation because the records no longer agree.

That distinction matters. A failed control is visible. An alignment problem can stay hidden until the end: the institution declares one architecture type, fieldwork follows a different boundary, evidence is collected from the wrong system, or remediation is marked closed without the assessment conclusion being revisited.

One review catches most of these problems: give the final pack to somebody who was not involved in fieldwork and ask them to trace the KYC-SA position back through the report, the evidence and the architecture. If they need a long verbal explanation, the pack is not ready.

The records should tell the same story

Before sign-off, reconcile the assessment in this order:

KYC-SA status  →  architecture  →  scope  →  evidence  →  assessment conclusion  →  remediation / reassessment

A change near the start of that chain should be reflected downstream. If a new connector changes the boundary, the scope and evidence set may need to change. If a finding is remediated, the report and KYC-SA working status may also need to change. Rework is usually the cost of discovering one of those changes late.

1. KYC-SA and the assessment report disagree

This often happens because KYC-SA preparation and assessment fieldwork run in parallel. The attestation owner starts from last year's answers or a readiness tracker. The assessor then changes a control conclusion during testing, but the working KYC-SA file never catches up.

A common example is privileged access. The institution marks the control compliant because MFA is enforced on the main SWIFT application. Fieldwork later finds an administration route through a jump host that is outside that MFA path. The report now contains a deviation while the attestation working copy still says compliant.

Applicability causes the same problem. A control may be marked not applicable in the KYC-SA workbook because the team is using an old architecture assumption, while the assessor has treated it as applicable after reviewing the current design. Compensating explanations and partial remediation can drift in exactly the same way.

Before report sign-off, reconcile the controls one by one. For every applicable control, the attestation owner should be able to see the assessed status, any open deviation, the remediation state and the final position that will be entered in KYC-SA. A separate spreadsheet can help manage the work, but the signed-off report should remain the authoritative assessment record.

2. The architecture diagram is technically correct but operationally incomplete

SWIFT architecture diagrams often fail in subtle ways. The obvious SWIFT servers are there. The systems that can administer them, feed them or materially affect them are missing.

That can include operator workstations, customer connectors, shared Active Directory services, hypervisors, privileged-access tooling, jump hosts, remote-support paths, disaster-recovery components and outsourced infrastructure. None of those needs “SWIFT” in its product name to matter to the assessment.

The diagram is part of the scoping evidence. It should show how transactions and administration actually move through the environment, where trust boundaries sit, which components are shared, and where a third party has operational control. A neat network picture that leaves out those relationships creates false confidence because the assessor ends up testing the drawing rather than the real dependency chain.

Take each in-scope SWIFT component and ask who can change it, what can send data to it, what it depends on for identity and administration, and how support reaches it. New middleware, a managed jump service or a connector introduced mid-year is exactly the sort of change that should trigger another look at scope.

3. The evidence proves intent, not operation

Policies are useful, but they answer only one question: what should happen. A SWIFT CSP assessment also needs enough evidence to establish what is configured and what actually happened in the environment being assessed.

Take a quarterly privileged-access review. The policy may say the review is mandatory. The stronger evidence set is the user population that was reviewed, the completed review record, the approver, any removal or change tickets, and confirmation that those changes reached the relevant systems. The assessor can then connect the process requirement to the control in operation.

The same distinction appears in MFA, firewall review, vulnerability management and monitoring. A screenshot taken today supports the current configuration. It cannot establish that a review happened three months ago. A procedure explaining how alerts are handled does not show that a real alert was investigated or escalated.

Weak evidence packs often look polished because they contain many documents. Volume is a poor substitute for traceability. Evidence becomes useful when it ties the control to the right component, the right period and a result the assessor can independently verify.

4. Scope follows the SWIFT asset list and misses the routes into it

The assessor has to understand more than the list of servers labelled as SWIFT. Administrative and transaction paths can bring shared infrastructure into the assessment even when those systems sit outside the obvious SWIFT zone.

Consider a SWIFT operator workstation joined to the corporate domain, a virtualised SWIFT server managed from a shared platform, or remote support that lands on a common jump host. Compromise of those dependencies may give an attacker a route to an in-scope component. The scope decision therefore needs to record how the dependency is treated and what assurance supports that decision.

Third parties create a similar issue. An ISO 27001 certificate or SOC report can be useful background assurance. It does not automatically answer the SWIFT-specific question. The assessor still needs to know which service the provider operates, which CSCF control relies on that service, what the assurance period and boundary cover, and whether any gap remains for the institution to assess directly.

A compact dependency register is often more useful than another policy document. It can identify the shared service, the relationship to the SWIFT environment, the owner, the control that depends on it and the evidence used to support the scope decision.

5. Remediation is closed before the assessment conclusion is revisited

Closing a remediation ticket records that somebody made a change. The assessment conclusion changes when the assessor has suitable evidence of the corrected state and, where required, performs the appropriate reassessment.

Suppose fieldwork finds an unnecessary network path into the SWIFT environment. The network team removes the rule and closes the change request. That proves a configuration change was made. The assessment file still needs the corrected-state evidence and enough independent validation to support any revised control conclusion.

The closure record should make the sequence obvious: the affected control, the component involved, what was wrong, the corrective action, the owner, the date, the evidence used for closure and the reassessment result. When those details live only in email or ticket comments, they are easy to lose during KYC-SA reconciliation.

This is also where target dates matter. A control that remains open at attestation time should be represented consistently in the report and the KYC-SA position. Moving a date in a remediation plan does not change the assessed state of the control.

Before KYC-SA, run one reconciliation pass

A focused quality review normally exposes the weak hand-offs quickly. Pick controls from different areas and trace each one from the KYC-SA working status back to the report, component, evidence and any remediation record.

• Confirm the current architecture type and the as-built diagrams used for the assessment.
• Check that control applicability and status in the KYC-SA working copy match the final assessment.
• Trace a sample of controls to evidence from the actual SWIFT environment, not a generic enterprise control.
• For shared services and third parties, record the dependency and the assurance relied on.
• For remediated findings, keep the corrected-state evidence and the assessor's reassessment result with the finding.

If a reviewer can complete that trace without asking the network team to explain what the diagram “really means”, the pack is probably ready. If the explanation depends on emails, memory or a spreadsheet that contradicts the report, close that gap before KYC-SA.

A note on the word “rejected”

There is a useful SEO phrase here, but the terminology should stay accurate. People do search for “SWIFT CSP report rejected” and similar wording. In practice, the independent assessment supports the KYC-SA attestation; the full report is not simply uploaded for a routine pass/fail decision by Swift in every case. Rework can happen before submission, during internal quality review, during reconciliation with KYC-SA, or later if the quality of an assessment is reviewed.

For that reason, this article uses “rework” rather than claiming a Swift-wide rejection rate. A percentage should only be published if it comes from a clearly identified dataset and is described as that organisation's sample, not as a Swift statistic.

The point of the final report

A SWIFT CSP assessment report should make the institution's attestation position easy to reconstruct. Architecture explains the boundary. Scope explains what was assessed. Evidence supports the control conclusion. Findings show where the control fell short. Reassessment records what changed before closure.

When those records agree, KYC-SA preparation is straightforward. When they do not, the last week of the assessment turns into document archaeology. That is the rework worth preventing.

Related RedSecLabs guidance:

For control-level preparation, see SWIFT CSP Assessment Checklist 2026: Evidence & Scope.

For independent assessment support, see SWIFT CSP Assessment Services.