SWIFT CSCF
Evidence request list. 34 controls, 34 carrying auditor artefact guidance. Generated from the compliance knowledge graph on 12 September 2026. Published by The Art of Service.
Attack Surface
Per SWIFT CSCF Objective 2: Internal Data Flow Security + Security Updates + Hardening + System Integrity Verification + Application Hardening + Vulnerability Scanning + Logging + Anti-Virus.
- SWIFT CSCF evidence for SWIFTCSCF-2
- attestation + independent assessment partial
Attestation
Per SWIFT CSCF: annual Customer Security Programme attestation in KYC-SA portal + independent assessment per Mandatory + Advisory controls + maintain documentation.
- SWIFT CSCF evidence for SWIFTCSCF-8
- attestation + independent assessment partial
Credentials
Per SWIFT CSCF Objective 4: Password Policy + Multi-Factor Authentication + Operator Session Confidentiality + Privileged Access.
- SWIFT CSCF evidence for SWIFTCSCF-4
- attestation + independent assessment partial
Detection
Per SWIFT CSCF Objective 6: Malware Protection + Software Integrity + Database Integrity + Logging and Monitoring + Intrusion Detection.
- SWIFT CSCF evidence for SWIFTCSCF-6
- attestation + independent assessment partial
IR
Per SWIFT CSCF Objective 7: Cyber Incident Response Planning + Security Training and Awareness + Penetration Testing + Scenario Risk Assessment + cooperate with SWIFT ISAC.
- SWIFT CSCF evidence for SWIFTCSCF-7
- attestation + independent assessment partial
Identity
Per SWIFT CSCF Objective 5: Logical Access Control + Token Management + Personnel Vetting + Physical and Logical Password Storage.
- SWIFT CSCF evidence for SWIFTCSCF-5
- attestation + independent assessment partial
Objective 1: Restrict Internet Access and Protect Critical Systems
Isolate the SWIFT secure zone from the broader corporate network and from public networks so that lateral movement from less trusted zones is blocked.
- zone diagram with the SWIFT secure zone clearly delineated
- firewall ruleset between SWIFT and other zones
- policy describing permitted traffic types and direction
- evidence of regular firewall rule review
- any to any rules left in place from migration
- operator workstations spanning multiple zones
- shared directory services across the boundary
Tightly control administrator level operating system accounts on SWIFT components, with named ownership, strong authentication, and full activity logging.
- inventory of admin and root accounts on SWIFT hosts
- PAM vault rotation logs
- session capture configuration for privileged sessions
- approval workflow for privileged access requests
- shared root credentials across multiple admins
- remote management protocols accessible without jump host
- no review of privileged session recordings
Apply the same level of protection to hypervisors and management planes that host SWIFT virtual machines as to the SWIFT components themselves.
- hypervisor hardening standard
- evidence that SWIFT VMs do not share hosts with internet exposed workloads
- patch records for hypervisor hosts
- access control matrix for hypervisor management
- SWIFT and general workloads on the same cluster without affinity rules
- management interfaces reachable from corporate LAN
- missing MFA on hypervisor management consoles
Prevent direct internet connectivity to or from systems inside the SWIFT secure zone, channelling any required external traffic through controlled intermediaries.
- egress firewall rules with default deny
- proxy logs for traffic leaving the secure zone
- exception register for outbound flows
- verification scan from inside the zone showing no direct internet reachability
- Windows Update servers reachable directly
- telemetry agents calling vendor cloud endpoints
- DNS resolution from public servers
Objective 2: Reduce Attack Surface and Vulnerabilities
Protect data in transit between SWIFT components using strong encryption and mutual authentication so that internal flows cannot be intercepted or replayed.
- TLS configuration evidence for each component connection
- certificate inventory with key length and algorithm
- configuration disallowing legacy protocols
- monitoring for unencrypted internal traffic
- plain LDAP used for directory binds
- TLS 1.0 still enabled on legacy components
- self signed certificates without rotation
Manage Relationship Management Application authorisations so that only intended counterparties can exchange specific message types with the institution.
- RMA inventory with active relationships and message types
- process for adding, modifying, and revoking RMA authorisations
- evidence of periodic review of RMA relationships
- dormant RMA relationships not revoked
- broad message type permissions where narrower scope would suffice
- no periodic RMA review
Implement a documented process to evaluate, test, and apply security updates to SWIFT components within risk based timeframes.
- patch policy with severity based SLAs
- patch deployment evidence for SWIFT components
- vulnerability scan trend before and after patching
- exception register with compensating controls
- frozen change windows blocking patches indefinitely
- SWIFT Alliance components running unsupported releases
- no tracking of vendor end of life
Apply hardening baselines that disable unnecessary services, accounts, and software on SWIFT components and supporting systems.
- hardening baseline per platform with reference to a benchmark
- configuration compliance scan results
- deviation register with risk acceptance
- build automation scripts where applicable
- default accounts not disabled
- compliance scans without remediation tracking
- missing baselines for appliances
Secure data flows between back office payment systems and the SWIFT messaging interface so that messages cannot be tampered with in transit.
- interface specifications between back office and SWIFT
- TLS or VPN configuration on each link
- message integrity controls
- monitoring of integration availability and errors
- shared folder drop without encryption
- missing integrity checks on batch files
- test interfaces left enabled in production
Protect SWIFT related data when transmitted or stored outside the secure zone, including backups, archives, and outsourced processing locations.
- backup encryption configuration
- media handling procedures
- third party encryption attestations
- DLP rules for SWIFT data egress
- unencrypted tape rotation to offsite vault
- cloud backups without customer managed keys
- third party copies without contractual protection
Protect interactive operator sessions to SWIFT applications with encryption, inactivity locking, and timeout limits.
- session timeout settings in messaging interface
- screen lock policy for operator workstations
- encryption settings for operator session protocols
- unattended workstations without screen lock
- long lived sessions persisting overnight
- remote desktop sessions without encryption
Run regular authenticated vulnerability scans of SWIFT systems and feed findings into a tracked remediation process.
- scan schedule covering all SWIFT components
- authenticated scan results
- remediation tracking with severity based SLAs
- evidence of scanning of hypervisors and supporting infrastructure
- unauthenticated scans missing application weaknesses
- scans run but reports not actioned
- scope excluding network appliances
When SWIFT related activities are outsourced, ensure that the provider applies controls that meet the institution's CSCF obligations and is subject to oversight.
- list of outsourced SWIFT related services
- provider attestations or independent assessments
- contractual security clauses
- service level reviews
- service providers with privileged access not assessed
- no right to audit clauses
- absence of breach notification clauses
Implement business level controls on payment activity, including allow listed counterparties, value limits, time windows, and dual authorisation for high risk transactions.
- limit and allow list configuration
- dual authorisation workflow documentation
- examples of blocked or alerted transactions
- review of exceptions and overrides
- limits configured but not monitored
- weekend or holiday windows not enforced
- single approver allowed for high value payments
Objective 3: Physically Secure the Environment
Protect the physical premises hosting SWIFT components against unauthorised access, environmental threats, and tampering.
- physical access policy
- data centre access logs
- CCTV coverage records
- environmental monitoring evidence
- asset tagging for SWIFT hardware
- shared racks without locked compartments
- physical access list not reviewed
- no environmental monitoring for power or cooling
Objective 4: Prevent Compromise of Credentials
Enforce a password policy that requires sufficient length, complexity, history, and rotation, and apply it consistently across all accounts that touch SWIFT components.
- password policy document
- directory configuration showing enforcement
- local account audit on appliances
- user awareness training records
- local accounts exempt from policy
- non expiring service accounts
- shared passwords for break glass scenarios
Require multi factor authentication for interactive access to SWIFT components, including operator, administrator, and emergency access flows.
- MFA configuration in messaging interface and jump servers
- MFA enrollment report
- policy mandating MFA for all interactive access
- evidence MFA covers emergency procedures
- MFA at perimeter but not at console
- exemptions for executives
- phone based factors without protection against SIM swap
Objective 5: Manage Identities and Segregate Privileges
Manage user access to SWIFT components on a least privilege and need to know basis, with formal joiner mover leaver procedures and recurring access recertification.
- role catalogue for SWIFT operations
- access request and approval records
- leaver revocation evidence
- recertification reports for SWIFT roles
- dormant accounts retained for years
- movers accumulating privilege
- recertification approvals without scrutiny
Manage hardware tokens, smart cards, and HSM keys used to authenticate to SWIFT components with strict issuance, storage, and revocation procedures.
- token inventory
- HSM operations procedures
- key ceremony records
- revocation procedures and evidence
- lost tokens not revoked promptly
- shared tokens for emergency use
- no dual control for sensitive HSM operations
Vet personnel who hold privileged access to SWIFT components in line with local law and the sensitivity of the role.
- vetting policy
- background check records for privileged staff
- third party staff vetting attestations
- revetting schedule
- contractors not vetted to same standard
- vetting expired without renewal
- no checks for transferred staff from other jurisdictions
Protect repositories where passwords, hashes, and recovery credentials are stored against unauthorised access and tampering.
- password vault configuration
- vault access logs
- policy for emergency credential storage
- review of vault administrator activity
- passwords in spreadsheets or chat tools
- vault administrators able to view secrets without ticket
- break glass envelopes not rotated
Objective 6: Detect Anomalous Activity to Systems or Transaction Records
Maintain malware protection on SWIFT components and supporting systems, with current signatures or behavioural detection and central reporting.
- antivirus or EDR coverage report
- signature update logs
- alert handling procedure
- exclusions list with justification
- servers excluded for performance reasons
- outdated signatures on isolated hosts
- EDR not reporting to central console
Capture security relevant events from SWIFT components, forward them to a protected log store, and monitor for anomalies and suspicious activity.
- log source inventory
- SIEM ingestion screenshots
- detection rules for SWIFT specific events
- retention policy and proof of retention
- messaging interface logs not forwarded
- log retention shorter than regulatory requirement
- no alerting on operator account anomalies
Detect and respond to intrusion attempts targeting SWIFT components through network or host based detection tooling.
- IDS or IPS coverage diagram
- signature and rule update logs
- alert handling runbook
- tuning records for false positives
- IDS deployed but not monitored
- rules outdated
- encrypted traffic blind spots without compensating controls
Objective 7: Plan for Incident Response and Information Sharing
Maintain an incident response plan with SWIFT specific scenarios, defined roles, escalation paths, and procedures for engaging SWIFT and the wider community when needed.
- incident response plan
- SWIFT specific playbooks for payment fraud and zone compromise
- tabletop exercise records
- post incident review reports
- generic plan without SWIFT scenarios
- no rehearsed payment recall process
- out of date contact list for SWIFT CSIRT
Provide regular training and awareness for staff with SWIFT related responsibilities so they can recognise threats and respond appropriately.
- training plan for SWIFT operators and administrators
- attendance and completion records
- phishing simulation results for in scope staff
- role specific training content
- generic training without SWIFT context
- no refresh training after major incidents
- low completion rates without follow up
Physical Security
Per SWIFT CSCF Objective 3: Physical Security including data centre + administrator workstations + media.
- SWIFT CSCF evidence for SWIFTCSCF-3
- attestation + independent assessment partial
Restrict Internet
Per SWIFT CSCF: SWIFT Environment Protection + Operating System Privileged Account Control + Virtualisation Platform Protection + Restriction of Internet Access + Customer Environment Protection (Architecture A/B). Implement controls per Architecture Type.
- SWIFT CSCF evidence for SWIFTCSCF-1
- attestation + independent assessment partial
Assembled from the framework’s own control set, so this list is regenerated rather than written and stays current as the graph does. See the SWIFT CSCF framework page.