PCI DSS by industry
PCI DSS for banks and financial services: acquirer oversight, card operations and the evidence a QSA samples
What changes when the entity is a bank: its role as acquirer, what belongs in scope across card, core, ATM, branch and contact centre operations, where assessors sample, and how PCI DSS sits beside SAMA CSF and DORA.
Key points
- A bank meets PCI DSS from both sides: as an acquirer it oversees its merchants' compliance, and as an entity that stores, processes and transmits card data it must protect its own cardholder data environment.
- The scope usually runs well beyond the card management system: core banking links, ATM and branch channels, contact centres, dispute teams and the processors you outsource to.
- Assessors spend most of their sampling on stored account data, privileged access, logging and testing across a large estate, and on how you oversee third-party processors.
- In Saudi Arabia the central bank's Cyber Security Framework names PCI DSS compliance as a requirement, so the two programmes share one evidence base.
Why banks and financial institutions need PCI DSS
The PCI Security Standards Council defines an acquirer as an entity, typically a financial institution, that processes card transactions for merchants. The card brands and acquirers enforce compliance, not the Council, and under Mastercard's programme merchants submit their validation documents to the acquiring bank, which oversees compliance and reports status to the brand when required. Your merchant services team reviews those AOCs and SAQs yearly.
The bank is also in scope in its own right. Issuing cards, authorising transactions, running ATMs and handling disputes all mean storing, processing or transmitting cardholder data, and sensitive authentication data such as PINs and PIN blocks passes through several of them.
With an estate this large and old, the programme succeeds when it starts from an accurate map of card data flows, not from policies.
What sits inside the scope for a bank
The cardholder data environment covers the systems, people and processes that handle card data, plus anything with unrestricted connectivity to them. In a bank that typically means the card management and authorisation systems, ATM and branch terminal networks, digital banking where card numbers are shown or entered, contact centres, dispute and fraud teams, and any data warehouse receiving full card numbers.
Outsourced processors, hosting and contact centres remain your responsibility: each needs a current AOC covering your services and a responsibility matrix.
Three scope mistakes recur in banks: assuming the core banking platform is out of scope when it holds full card numbers or connects to the CDE without restriction; forgetting card numbers kept in e-mail, spreadsheets and scanned dispute files; and treating a flat internal network as segmented because a diagram says so. The method for reducing scope is in PCI DSS scoping and segmentation: shrinking the CDE.
Where the requirements bite in banking
| Requirement area | What it means in a bank | Evidence the assessor samples |
|---|---|---|
| 3 Protect Stored Account Data | Full card numbers kept only where needed, sensitive authentication data never retained after authorisation, stored numbers unreadable | Data discovery results, retention and purge records, masking on staff screens, tokenisation or encryption with key management |
| 7 and 8 Access by need to know, identification and authentication | Branch, contact centre and database staff see only what their role requires; administrators use controlled privileged access | The access model by role, approved requests, six-monthly access reviews with their decisions, MFA configuration for all access into the CDE, leaver records |
| 9 Restrict Physical Access to Cardholder Data | Data centres, card stock and media, and the terminals in branches that capture card data | Badge and visitor logs, media inventory with destruction records, terminal inspection records, training for branch staff |
| 10 and 11 Logging, monitoring and testing | Logs from a large, mixed estate reviewed with automated tools; scans, penetration tests and segmentation tests proving the CDE is isolated from the corporate network | Daily log review evidence, passing quarterly ASV scans, internal scan results, penetration and segmentation test reports with fixes |
| 12 Policies, programmes and third-party service providers | Processors and outsourced services managed as part of your compliance, scope confirmed yearly, incidents rehearsed | Provider register with AOCs and responsibility matrices, the annual scope confirmation, targeted risk analyses, an exercised incident plan |
All twelve requirements are explained in PCI DSS requirements explained, requirement by requirement.
Working alongside central-bank cyber rules, SAMA CSF and DORA
Banks rarely meet PCI DSS in isolation. In Saudi Arabia, the Cyber Security Framework of the Saudi Central Bank lists compliance with PCI DSS, the EMV technical standard and the SWIFT Customer Security Controls Framework among its risk and compliance requirements, and points payment systems to the SARIE and mada rules; see SAMA CSF compliance. In the European Union, the Digital Operational Resilience Act applies to banks and payment firms and asks for ICT risk management, incident reporting, resilience testing and a register of ICT third-party arrangements; see DORA compliance.
None replaces the others, but access reviews, logging, vulnerability management, penetration testing and third-party oversight can be run and evidenced once, then mapped to each. Where the bank also holds ISO/IEC 27001 certification, the payment controls sit inside that management system; see PCI DSS vs ISO/IEC 27001 and SOC 2.
What a banking engagement looks like
Duration depends on how well card data flows are documented, how many legacy systems hold full card numbers, whether tokenisation or segmentation is needed, and the QSA's calendar. Card operations, IT, information security, contact centre and branch operations, procurement and internal audit must be involved, with a sponsor who can prioritise change on shared platforms. An Internal Security Assessor can test controls before the QSA arrives; see PCI DSS internal audit and the ISA: testing your own controls. With Design™, Sterling guides your teams to own the controls; with Drive™, Sterling carries more of the evidence, documentation and readiness testing.
How Sterling works with banks and financial institutions
One map of card data across every channel, one evidence base for every obligation.
Our expert and experienced consultants trace card data through every channel, reduce the scope where the architecture allows, test each requirement the way the QSA will and keep the evidence in Effivity, included with the engagement, at no additional cost. Sterling does not validate compliance; the QSA assesses and attests. We ensure successful validation for our clients.
Book a free discovery callPCI DSS for banks: questions buyers ask
Does PCI DSS apply to a bank that only issues cards?
Yes. PCI DSS applies to every organisation that stores, processes or transmits cardholder data or sensitive authentication data, and issuing and authorising card transactions does all three. The validation expected of you is set by the card brands' programmes.
Can our internal audit team carry out the PCI DSS assessment?
Only in part, unless your acquirer and the card brands permit otherwise. Internal Security Assessors perform internal assessments and work with the QSA; acceptance of an ISA-completed report is the brands' and acquirer's decision.
How do we check that our card processor is PCI DSS compliant?
Ask for its current AOC and check that it covers the services you use. Record it with a responsibility matrix and review it each year; see How to verify a PCI DSS AOC and check a provider's compliance.
Do central-bank cyber rules replace PCI DSS for banks?
No. SAMA's Cyber Security Framework, for example, requires PCI DSS compliance rather than replacing it, and DORA addresses ICT resilience, not card data. One shared control set can supply evidence to each.
PCI DSS by industry
Every guide in the PCI DSS series is written for one question and links back to the hub for the whole picture.
- The PCI DSS annual cycle
- PCI DSS assessor questions
- PCI DSS in Australia
- PCI DSS for banking and financial services
- PCI DSS for BPO and contact centres
- PCI DSS checklist
- Choosing a QSA
- PCI DSS for e-commerce and retail
- PCI DSS for fintech and payment facilitators
- PCI DSS for healthcare providers and insurers
- PCI DSS for hospitality and travel
- PCI DSS for software and hosting providers
Keep exploring
Explore more about PCI DSS
Watch a video on how to implement PCI DSS here.
Watch a video on PCI DSS requirements here.
PCI DSS resources
Services for PCI DSS
Talk to a consultant
Plan a PCI DSS programme that covers every card channel in your bank.
Tell us your goals, locations and target date. We’ll help you define the scope, timeline and next steps.
hello@sterling-grc.com+1 201 263 4443 (global headquarters) · your nearest office and its number are at the top of this page
What would you like to achieve?
Choose a starting point. The enquiry form takes about a minute.
Book my free discovery callContinue to the enquiry form to share your details. Please do not include passwords, sensitive personal information or confidential files. A Sterling consultant replies within one working day. Privacy notice