PCI DSS in 2026: A Comprehensive Guide for Retailers and Social Housing Providers

Introduction

Organisations that accept card payments are required to handle cardholder data securely. PCI DSS v4.0.1 is the current standard, and the PCI Security Standards Council (PCI SSC) provides comprehensive materials including the standard itself, the Quick Reference Guide, and the ROC and AOC templates that all organisations must follow.

This guide explains the 12 PCI DSS requirements, Self‑Assessment Questionnaires (SAQs), merchant levels, service provider levels and assessment expectations. It also provides sector‑specific context for retailers and social housing providers, including the use of allpay by many housing associations.

Are You in Scope for PCI DSS?

Use the following simple checks to determine whether you are in PCI scope. This is not a full assessment but a quick way to understand your likely obligations.

Check 1: Do you store cardholder data?

Storing any Primary Account Number (PAN) electronically
Storing any Sensitive Authentication Data (SAD), even briefly, such as CVV
If yes, you are in scope and will likely require SAQ D or a ROC.

Check 2: Do you transmit cardholder data?

Sending card data through your phone systems
Processing card details on your website
Accepting card details manually and keying into a system
If yes, you are in scope.

Check 3: Do you process cardholder data?

Using POS terminals
Using a virtual terminal
Operating an e‑commerce site
If yes, you are in scope.

Check 4: Does your technology influence cardholder data security?

Does your website load scripts that could modify a payment page
Does your infrastructure host systems that interact with payments
If yes, you are in scope even if you do not directly store or process card data.

Check 5: Are you using a service provider?

If your provider handles cardholder data for you, you must ensure they are PCI validated and may still have some PCI obligations yourself. PCI SSC emphasises this in its standards guidance.

Quick Interpretation

If you do not store, process or transmit card data and your systems cannot influence payment security, you may qualify for SAQ A.
If your environment touches card data in any way, you are in the PCI DSS scope.

Understanding Key Roles: Merchant and Service Provider

Before approaching PCI DSS obligations, it is essential to understand two foundational categories.

What is a Merchant?

A merchant is any entity that accepts payment cards displaying the logos of the PCI SSC founding brands for goods or services. This definition applies across retail and social housing. If an organisation processes card transactions via POS, e‑commerce, mobile applications, virtual terminals or automated phone payments, it is considered a merchant. This definition appears in widely referenced PCI explanations and Mastercard’s Site Data Protection guidance.

In practice:

A retailer accepting card payments in store or online is a merchant.
A housing provider taking rent payments via web portals, IVR or call centres is also a merchant.

What is a Service Provider?

A service provider is any entity that stores, processes or transmits cardholder data on behalf of another organisation, or could influence the security of a cardholder data environment (CDE). This includes payment gateways, hosting providers, SaaS billing platforms, tokenisation services, managed firewall providers and call‑masking providers.

Examples:

allpay functions as a service provider for social housing by processing payments and offering related services. Housing associations rely on allpay because of its extensive PCI programme and Level 1 compliance.
Eckoh and PCI Pal, accessed through allpay, offer call‑masking solutions that protect card data during phone payments.

Understanding merchant and service provider roles is essential because each category has different PCI obligations.

1. Summary of the 12 PCI DSS Requirements

Below is a clear and practical explanation of each requirement.

1. Install and maintain network security controls

Organisations must ensure networks are segmented, access paths are restricted and firewall rules are maintained. Retail POS networks and housing management systems must be separated from payment systems.

2. Apply secure configurations

All systems must be hardened. Vendor defaults cannot be used, and only essential services should remain active.

3. Protect stored account data

Minimise storage and apply strong encryption if holding cardholder data is unavoidable. Sensitive Authentication Data must never be retained.

4. Protect card data during transmission

Any transmission of cardholder data across open networks must be encrypted using strong protocols.

5. Protect systems from malware

Malware detection and prevention must be in place and updated regularly. POS may require allow‑listing controls.

6. Maintain secure systems and software

Systems and software must be updated and patched. E‑commerce platforms and payment portals require regular security reviews.

7. Restrict access to cardholder data

Access must be limited to individuals whose roles require it. Least privilege is vital for internal and external users.

8. Identify and authenticate users

Unique credentials are required and multi‑factor authentication must be used for administrative and remote access.

9. Restrict physical access

Physical areas storing or processing cardholder data must be secured.

10. Log and monitor access

Logging must be centralised, tamper resistant and actively monitored. This helps identify suspicious activity.

11. Test systems and processes

Organisations must conduct regular testing, including ASV scans and penetration testing. PCI DSS v4.x stresses continuous monitoring.

12. Maintain an information security policy

Policies, procedures and training must be maintained to support compliance.

2. Self‑Assessment Questionnaires (SAQs)

SAQs depend on how the organisation accepts card payments.

SAQ A: For fully outsourced card‑not‑present environments. Common in social housing using hosted payment pages and IVR.
SAQ A‑EP: For e‑commerce merchants whose websites can impact payment page security.
SAQ B / B‑IP: For standalone terminals with no electronic storage.
SAQ C‑VT: For manual entry into a virtual terminal.
SAQ C: For internet connected payment applications without cardholder data storage.
SAQ P2PE‑HW: For merchants using validated P2PE terminals.
SAQ D: For merchants and service providers whose environments do not qualify for other SAQs.

Descoping and DTMF Call Masking

Call‑masking solutions allow tenants or customers to enter card details through DTMF tones that are converted into flat tones before reaching the contact centre. This prevents card data from entering systems and recordings, keeping the organisation out of scope for telephone cardholder data handling. Solutions provided through Allpay and its partners enable housing providers to qualify for SAQ A for phone payments.

3. Merchant Levels (1 to 4)

Merchant levels are based on annual transaction volumes. Mastercard’s Site Data Protection criteria serve as a clear reference. [pcicompliance.com]

Level 1: More than 6 million transactions per year. Requires annual ROC by a QSA, quarterly ASV scans and an AOC.
Level 2: Between 1 million and 6 million transactions per year. Requires annual SAQ and quarterly ASV scans.
Level 3: Between 20,000 and 1 million e‑commerce transactions. Requires annual SAQ and quarterly ASV scans.
Level 4: All other merchants below Level 3 thresholds (less than 20,000 annual transactions). Requirements vary by acquirer.

Acquirers determine the final validation path for each merchant.

4. Service Provider Levels

Service provider requirements differ from merchant requirements.

Level 1: More than 300,000 transactions. Requires a ROC, quarterly ASV scans and an AOC.
Level 2: Less than or equal to 300,000 transactions. Requires SAQ D (Service Provider) and quarterly ASV scans. Some customers may request Level 1 validation.

5. Assessments: ROC, QSA and ISA

Report on Compliance (ROC)

A ROC is a formal PCI DSS assessment performed by a Qualified Security Assessor (QSA) for Level 1 merchants and Level 1 service providers. It results in a detailed report and an Attestation of Compliance.

Qualified Security Assessor (QSA)

A QSA is an independent assessor trained and approved by the PCI Security Standards Council to evaluate PCI DSS compliance. PCI SSC emphasises the role of QSAs and maintains a global list of approved assessors.

Internal Security Assessor (ISA)

An ISA is an internal employee trained through PCI SSC’s ISA programme. An ISA may support internal preparation and evidence gathering, but ROCs for Level 1 entities must still be signed off by an appropriate assessor, depending on scheme and acquirer requirements.

6. Financial Penalties

PCI SSC does not issue fines directly. Card brands and acquirers enforce penalties if a merchant or service provider is non‑compliant or suffers a breach while non‑compliant. Typical consequences include:

Fines issued by card brands through the acquirer
Increased transaction fees
Mandatory forensic investigations
Liability for fraud losses
Possible termination of card processing privileges

These enforcement mechanisms are reflected throughout card brand compliance documentation and merchant level criteria.

7. Industry Context: Retailers and Social Housing Providers

Retailers

Retailers operate in environments with integrated POS systems, third‑party components, web scripts and complex change management. PCI SSC merchant resources highlight the risks of malware, phishing and remote access in retail settings. [masterblogging.com]

Social Housing

Housing providers rely on multi‑channel payment services from providers such as AllPay, which supports hundreds of associations and maintains PCI DSS Level 1 compliance.

Call‑masking solutions help providers reduce PCI scope and improve tenant confidence.

Acquiring Banks

Acquiring banks play a central role in PCI DSS compliance. They:

Hold responsibility for ensuring their merchants validate PCI compliance
Set specific validation requirements for each merchant level
Submit compliance status to card schemes where required
Enforce deadlines and may apply penalties for non‑compliance

PCI SSC highlights that entities must work closely with acquirers to confirm whether they are required to validate PCI DSS compliance.

Merchants must maintain ongoing communication with their acquirers, especially when adding new payment channels, outsourcing services or responding to a suspected breach. Acquiring banks may also request for you to undertake a formal report on compliance.

9. PFI (PCI Forensic Investigation): What Happens After a Breach

A PCI Forensic Investigation (PFI) is required when cardholder data is suspected or confirmed to be compromised. PFIs must be performed by a PCI SSC‑approved forensic investigator.

When is a PFI Required?

A PFI is mandated when:

A card brand or acquirer identifies a suspected or confirmed compromise
Fraud patterns indicate a common point of purchase
Suspicious activity suggests unauthorised access to cardholder data
The acquirer instructs the merchant to initiate a PFI

What PFIs Do

A PFI team will:

Determine whether cardholder data was exposed
Identify how the compromise occurred
Assess the systems involved
Provide a formal PFI report to payment brands and the acquirer
Recommend remediation to prevent further compromise

Your Responsibilities During a PFI

Organisations must:

Activate their incident response plan immediately
Preserve evidence without altering systems
Notify acquirers and relevant card brands
Provide full access to investigators
Ensure service providers cooperate

After the PFI

You may be required to:

Complete a full ROC annually for a period
Undertake additional monitoring or remediation
Demonstrate full PCI DSS re‑validation

Breaches can lead to significant financial consequences including fines, increased fees, forced migration to Level 1 validation and potential loss of card processing privileges.

10. Final Notes

The PCI SSC Document Library remains the central repository for authoritative PCI DSS information.
GRC Hub supports organisations with scoping, SAQ selection, evidence preparation, remediation planning and ongoing assurance.

Explore our PCI services.

Need more help?

Governance Risk & Compliance Hub LIMITED