Most SWIFT CSP pre-assessment checklists online are restatements of the control objectives. They tell you what the standard requires for your annual SWIFT attestation. They do not tell you what an assessor will actually request, what 'sufficient evidence' looks like for each control, or — most importantly — what gaps produce findings.
This checklist is different. It is written from the assessor's side of the table.
Every item on this list is something an assessor will ask for directly, observe in person, or inspect as documentation. This is the assessor's side of the table — not the standard's side.
Every item on this list is something an assessor will either ask for directly, observe in person, or inspect as documentation during a SWIFT CSP independent assessment. Where banks most commonly fall short is noted explicitly. The framework version is CSCF v2026 — if you are preparing for the current attestation cycle, this is the version that applies.
If you want to understand the broader assessment process before working through this checklist, start with the article on what the IAF actually requires during a SWIFT CSP independent assessment. This checklist is the practical companion to that overview — use both together.
Why Evidence Preparation Is a Months-Long Process, Not a Document Sprint
The single most common mistake banks make is treating evidence preparation as something that happens after the assessor is scheduled. It is not. Evidence preparation is an ongoing operational discipline that starts the day after your previous attestation is submitted.
Here is why. Assessors test controls at a point in time — but they need evidence that those controls were operating throughout the period, not just during the assessment window. A patch applied the week before the assessor arrives does not demonstrate a functioning security update process. An access review completed the day before the evidence request does not demonstrate that logical access is genuinely managed. Assessors know this, and they ask about it.
The attestation window runs July to December. If you start gathering evidence in October, you are already behind. The evidence for several controls — particularly logging and monitoring, security updates, and vulnerability scanning — needs to show activity over a sustained period. That activity either happened or it did not. No amount of document preparation changes what was actually done.
Use this checklist to identify what needs to be in place operationally, not just what needs to be in a folder when the assessor arrives.
How assessors test — the four IAF methods
Inquiry: the assessor asks questions. Policy documents and your explanation of how controls work. Inquiry alone is never sufficient for technical controls. Observation: the assessor watches a process in real time — operator login, token usage, session workflows. Inspection: the assessor examines documentation, configuration files, logs, and reports. Where most evidence effort should go. Re-performance: the assessor independently executes a procedure to verify the expected result. Used selectively for technical controls.
How to Use This Checklist — What "What Assessors Actually Look For" Means in Practice
Assessors use four testing methods, as defined in the SWIFT Independent Assessment Framework: inquiry, observation, inspection, and re-performance. Not every control is tested by all four — assessors choose the mix based on risk. But you should assume that any control where operational evidence exists will be inspected, not just discussed.
Inquiry — the assessor asks questions. This is where policy documents and your own explanation of how controls work are relevant. Inquiry alone is never sufficient to conclude compliance for technical controls.
Observation — the assessor watches a process happen in real time. This applies to things like operator login procedures, token usage, and session workflows.
Inspection — the assessor examines documentation, configuration files, logs, reports, and records. This is where most evidence preparation effort should go.
Re-performance — the assessor independently executes a procedure to confirm it produces the expected result. Used selectively for technical controls where configuration can be verified directly.
For each section below, the evidence items are organised by what an assessor would inspect. Policy documents are noted where relevant, but they are never sufficient on their own for technical controls.
Download the full evidence checklist — free PDF
The SWIFT CSP Pre-Assessment Evidence Checklist covers all 7 CSCF v2026 evidence categories in print-ready format. Built from real assessment experience — not a restatement of the control objectives.
Category 1 — Secure Zone and Environment Protection Evidence
Secure Zone and Environment Protection
These controls establish the boundary between your SWIFT environment and everything else. They are foundational — if an assessor has concerns about the secure zone design, every other control's value is reduced.
1.1 SWIFT Environment Protection
What assessors inspect
- Network diagram showing the secure zone boundary — current, dated, accurate to actual environment (not drawn for the assessment)
- Firewall ruleset governing inbound and outbound traffic — reviewed and signed off within past 12 months
- Evidence of periodic firewall rule review — changes formally approved and documented
- If using a jump server: configuration and access logs
Where banks fall short
The network diagram exists but does not match the actual firewall rules. Or rules were reviewed once years ago with no subsequent review record. Assessors cross-reference the diagram against the actual ruleset — mismatches create significant findings.
1.2 Operating System Privileged Account Control
What assessors inspect
- List of all privileged accounts on SWIFT-related systems (OS-level, not application-level)
- Evidence that privileged accounts are used only for privileged tasks — separate named accounts, not shared admin
- Access review records — who reviewed, when, and outcome
- Evidence that former employees' privileged access was revoked promptly on departure
Where banks fall short
Shared administrator accounts with no individual accountability. No access review record — "we review it informally" is not evidence. Stale privileged accounts for staff who have left.
1.3 Virtualisation Platform Protection
What assessors inspect
- Evidence that the hypervisor/virtualisation platform is patched and hardened
- Separation evidence — SWIFT VMs are not co-hosted with general business VMs without adequate controls
- Hypervisor access controls — who can manage the platform and what audit trail exists
Applies only if virtualisation is used in the SWIFT environment.
1.4 Restriction of Internet Access
What assessors inspect
- Confirmation SWIFT infrastructure has no direct internet access — firewall rules or architecture that prevents it
- For components requiring internet for updates: evidence access is restricted to specific destinations only
- Network diagram confirming the secure zone has no general internet path
1.5 Customer Environment Protection
What assessors inspect
- Network diagram showing operator environment and separation from general corporate IT
- Evidence that operator PCs are not used for general internet browsing or email without controls
- Configuration records for the operator environment showing applied hardening
Applies to the operator workstation environment — the zone from which operators access SWIFT.
Category 2 — Attack Surface and Vulnerability Management Evidence
Attack Surface, Vulnerability Management and Access Control
This category is where most findings cluster. These controls require sustained operational activity — not one-time configuration — and assessors will probe for evidence of ongoing process, not just current state.
2.1 Internal Data Flow Security
2.2 Security Updates
This is one of the highest-frequency findings in SWIFT CSP assessments.
2.3 System Hardening
What assessors inspect
- Hardening baseline or configuration standard for each in-scope system type
- Evidence hardening has been applied — configuration exports, CIS benchmark scan results, or equivalent
- Documented exceptions from baseline with compensating control rationale
- Evidence that hardening is reviewed and maintained after changes
Where banks fall short
A hardening policy document exists but no evidence it was applied to production systems. The document and the configuration are two separate things — assessors inspect both.
2.6 Operator Session Confidentiality and Integrity
What assessors inspect
- Evidence operator sessions use encrypted protocols (SSH, TLS — not telnet or HTTP)
- Session timeout configuration — inactive sessions are terminated
- MFA configuration for operator sessions where applicable
- Session monitoring or logging configuration
2.7 Vulnerability Scanning
What assessors inspect
- Most recent vulnerability scan report covering all in-scope SWIFT components — dated, correctly scoped
- Evidence scanning is performed regularly — quarterly is the typical expectation
- Remediation records — vulnerabilities identified were addressed with timelines
- Exception documentation for vulnerabilities that cannot be immediately remediated
Where banks fall short
The scan covers the main SWIFT interface but misses supporting components. Or scans are run but results not acted on — high-severity vulnerabilities sit open across multiple scan cycles. This is one of the highest-frequency findings.
2.8 Outsourced Critical Activity Protection
What assessors inspect
- SLA/NDA with each outsourcing agent explicitly referencing SWIFT CSP obligations
- Current security risk assessment specific to the outsourcing arrangement
- Evidence of the agent's SWIFT CSP compliance — their own attestation or a scoped third-party report
- Ongoing monitoring records — how the bank verifies continued compliance
Where banks fall short
A SOC 2 report exists from the agent but scope does not cover the CSCF controls relevant to the outsourced activity. Scope mismatch is the most common outsourcing evidence failure.
See the dedicated article on control 2.8 for the full evidence breakdown. In summary, assessors will look for: SLA/NDA with each outsourcing agent referencing SWIFT CSP, a current security risk assessment specific to the outsourcing relationship, and compliance evidence from each outsourcing agent covering the CSCF controls applicable to their scope.
2.9 Transaction Business Controls
What assessors inspect
- Documented transaction monitoring parameters — thresholds set, who owns them
- Evidence that monitoring alerts are reviewed — alert logs, investigation records
- Process documentation showing the alert triage and escalation workflow
- Evidence parameters are reviewed and updated periodically
2.10 Application Hardening
What assessors inspect
- Configuration records showing unnecessary features and services are disabled
- Evidence that default credentials have been changed
- Application-level access control configuration
- Evidence that hardening is reviewed following updates or changes
Category 3–5 — Physical Security, Credentials, and Access Control Evidence
3.1 Physical Security
4.1 Password Policy
What assessors inspect
- Password policy document covering SWIFT systems — length, complexity, expiry, history requirements
- Technical evidence the policy is enforced — Active Directory group policy export or equivalent
- Cross-reference showing policy document and technical configuration match
Where banks fall short
The policy says one thing and the technical configuration enforces something weaker. Policy and configuration must match — assessors check both and cross-reference them.
4.2 Multi-Factor Authentication
What assessors inspect
- Evidence MFA is enabled for all operator access to SWIFT components — configuration records, not just a policy
- Token management records — inventory of tokens, lifecycle management evidence
- Evidence of fallback procedure when MFA is unavailable
5.1 Logical Access Control
What assessors inspect
- Current user access list for all in-scope SWIFT systems — who has access, at what level
- Access review records — periodic review confirming access is appropriate, with evidence of who reviewed and when
- Evidence access rights are provisioned through a formal process — request, approval, implementation records
- Evidence access is removed promptly when personnel change roles or leave
Where banks fall short
The access list has stale accounts — former employees or contractors who no longer need access. No periodic review records. This is one of the most consistent findings across assessments.
5.2 Token Management
What assessors inspect
- Token inventory — all tokens associated with SWIFT operations and who they are assigned to
- Evidence of lifecycle management — issuance records, revocation records when personnel change
- Lost or stolen token procedure and records of any incidents
5.4 Password Repository Protection
What assessors inspect
- Evidence privileged passwords for SWIFT systems are stored in a secured credential vault
- Access controls to the password repository — who can access and how access is logged
- Evidence the vault is backed up and availability is maintained
Detection, Monitoring and Incident Response
Category 6–7 — Detection, Monitoring, and Incident Response Evidence
6.1 Malware Protection
What assessors inspect
- Anti-malware deployed on all in-scope systems — name, version, current signature date
- Evidence signatures are updated regularly — automatic update configuration or manual update records
- Scan schedule and recent scan results
6.2 Software Integrity
What assessors inspect
- Evidence SWIFT software is obtained from authorised sources — download records, checksums verified
- File integrity monitoring configuration or evidence, if applicable
- Records showing software versions in use are current and authorised
6.3 Database Integrity
What assessors inspect
- Evidence access to SWIFT-related databases is controlled and logged
- Database audit log configuration showing privileged access and changes are recorded
- Evidence database access is reviewed periodically
6.4 Logging and Monitoring
What assessors inspect
- Log configuration for each in-scope system — events logged, retention period, storage location
- Evidence logs are being reviewed — alert review records, monitoring dashboard activity, or SIEM evidence
- Evidence log retention period meets SWIFT requirements
- Evidence logs are protected from tampering — access controls to log storage
Where banks fall short
"We have logs" is not sufficient evidence. Assessors look for evidence of review and retention — not just configuration. Logs configured but never reviewed, or reviewed but with no records of that review, are findings.
This is one of the controls where "we have logs" is not sufficient evidence.
7.1 Cyber Incident Response Planning
What assessors inspect
- Current cyber incident response plan covering SWIFT-related incidents
- Evidence of testing — tabletop exercise or walkthrough records dated within past 12 months
- Contact list for SWIFT and regulatory notification in the event of an incident
- Training records for staff with SWIFT incident response responsibilities
Where banks fall short
The incident response plan exists but has never been tested. A plan that has not been exercised is not a functioning control — assessors will ask for evidence of the most recent test.
7.2 Security Training and Awareness
The Evidence Gaps That Most Commonly Produce Findings
Having reviewed evidence packages across multiple SWIFT CSP assessments, these are the gaps I see most often — not edge cases, but patterns. The authoritative source for control requirements is the SWIFT Customer Security Controls Framework, published at swift.com.
Policies without technical proof. A bank has a strong password policy document but the Active Directory settings enforcing it have different values. An access review policy exists but no records of reviews having occurred. Policy is intent. Evidence is reality. Assessors test reality.
Outdated network diagrams. The diagram submitted does not reflect changes made since the last assessment — a new server added, a firewall rule modified, a cloud component introduced. Assessors will probe mismatches between the diagram and the actual environment. An inaccurate diagram is worse than no diagram because it raises questions about what else might be inaccurate.
Incomplete scope. The main SWIFT interface is patched, hardened, and monitored — but the jump server used to administer it is not. Or the network device sitting at the secure zone boundary is running end-of-life firmware that nobody considered in scope. Scope gaps are consistently where findings cluster.
Evidence that covers the wrong period. A vulnerability scan run the week before the assessment does not demonstrate a functioning quarterly scanning process. A log review record from last month does not demonstrate ongoing monitoring. Assessors are assessing a point in time, but the evidence must show the controls were operating before they arrived.
Outsourcing agent evidence that doesn't hold up to scope verification. A SOC 2 report exists from the cloud provider or managed service partner. But the report's scope does not cover the specific CSCF controls applicable to the bank's architecture, or the production SWIFT environment is explicitly excluded. Filing a compliance report is not the same as verifying its coverage.
the components that administer or connect to the primary SWIFT systems.
Evidence Retention — What to Keep and For How Long
The IAF recommends retaining assessment evidence for five years — covering a minimum of two attestation cycles. This is not a hard regulatory requirement in all jurisdictions, but it is the SWIFT recommendation and assessors will ask about it.
In practical terms, this means: every document, log export, configuration record, screenshot, and report used in an assessment should be archived and preserved. If SWIFT requests additional evidence in a subsequent cycle or a counterparty questions your attestation, you need to be able to produce the evidence that supported it.
The evidence package should be stored securely — not in an individual's email or a shared drive with no access controls. Treat assessment evidence with at least the same care as you treat the SWIFT infrastructure it documents.
Evidence retention — the 5-year rule
The IAF recommends retaining assessment evidence for five years — covering a minimum of two attestation cycles. Every document, log export, configuration record, screenshot, and report used in an assessment should be archived and preserved. Store securely — not in an individual's email or a shared drive with no access controls.
Getting Your Attestation Evidence Package Ready Before the Window Opens
The July–December attestation window is not when evidence preparation starts. It is when the assessment happens. Evidence preparation is what happens in the months before that.
A practical timeline: by April, know which controls have evidence gaps from the previous cycle or from operational changes since the last assessment. By May, have remediation activities underway. By June, start organising the evidence package so that when the assessor is scheduled, you are not gathering documents under pressure.
Evidence preparation calendar — SWIFT CSP attestation cycle
Identify evidence gaps from prior cycle and operational changes since last assessment
Gap analysisRemediation underway — close patch gaps, access review findings, update configurations
RemediationOrganise evidence packages per control — version-controlled, dated, archived securely
Evidence packAssessment window. Evidence ready. Assessor engagement begins. Not the time to start.
AssessmentThe July–December attestation window is when the assessment happens — not when evidence preparation starts. Banks that begin in October are already three months behind.
The SWIFT CSP framework reference pages map each control's requirements in full technical detail for any control where you need to go deeper than this checklist takes you.
If you are working through evidence preparation and want a practitioner's assessment of where your package stands before the assessor arrives, that is a conversation I have regularly with banking clients. The consulting enquiry link is in the sidebar.
