Merchant
Retailers, restaurants, healthcare offices, ecommerce stores, professional services, nonprofits, hospitality, field services, and any business that accepts cards.
Merchant and service-provider applicability
Know Whether PCI DSS Applies Before You Sign the Attestation
Learn which businesses need PCI DSS compliance: merchants, ecommerce stores, restaurants, retailers, service providers, MSPs, payment vendors, and companies affecting the CDE.
Accepts cardsSupports payment systemsCan affect CDE security
Written for: Merchants, retail stores, restaurants, ecommerce companies, software providers, MSPs, SaaS providers, call centers, and vendors supporting payment systems.
PCI DSS Responsibility Follows Role and Influence
Merchants generally have PCI DSS responsibilities when they accept payment cards. Service providers can also have responsibilities when they store, process, transmit, secure, manage, host, support, or otherwise affect cardholder data for another organization.
The hard cases are the everyday ones: an MSP with remote admin access, a web developer who controls checkout code, a hosting provider with privileged access, a SaaS vendor that stores payment records, or a call center that accepts card payments for clients.
Role Map for Merchants, Vendors, MSPs, and Payment Teams
Service provider
A company that can affect the CDE through hosting, support, payment software, managed firewall services, backup access, logging, remote access, call handling, or data processing.
Technology vendor
Ecommerce platforms, POS vendors, payment gateways, virtual terminals, cloud providers, plugin vendors, and integrations that shape how card data moves.
Internal support team
Finance, operations, IT, office managers, developers, help desk staff, and administrators who can change systems in the payment path.
Decision Path Before Selecting the Validation Route
- 01
Identify card acceptance channels
In-person, ecommerce, phone, invoice link, recurring billing, mobile reader, stored credentials, refunds, and manual fallback processes.
- 02
List systems and vendors
POS, websites, gateways, CRM, accounting, email, ticketing, storage, backup, network devices, cloud consoles, and remote support platforms.
- 03
Clarify who can affect security
Administrators, vendors, MSPs, developers, finance staff, processor portals, hosting providers, and privileged service accounts.
- 04
Match requester expectations
Processor, acquirer, customer, payment brand, QSA, or service-provider client requirements may determine the validation package.
Why Outsourcing Does Not Remove All Responsibility
A hosted checkout page can reduce card-data exposure, but the merchant may still control the website page that redirects customers, the scripts around checkout, admin accounts, DNS, plugin updates, staff procedures, and incident communications.
The practical objective is to prove what the business does not store, narrow what it can affect, and document the vendor controls that support the remaining scope.
Questions that resolve role ambiguity
Whose transaction is it?
Determine whether the organization accepts payment for its own goods or services, operates payment functions for customers, or does both. Match merchant identifiers, contracts, entities, locations, and customer services to the correct role instead of treating the corporate group as one undefined environment.
Who can change security?
List every party able to alter checkout code, terminal configuration, firewall rules, cloud resources, identity, DNS, remote support, logging, backup, or vulnerability remediation. A party can influence PCI DSS scope even when it does not intentionally view account data.
Who produces evidence?
For each control, identify the source system, operator, reviewer, provider document, frequency, incident contact, and customer-facing evidence. If a vendor says it is responsible, confirm that the agreement and current attestation cover the exact service being relied on.
Who receives validation?
Record the acquirer, payment brand, processor, customer, or contract that requests the result. Confirm the form, entity, period, deadline, submission channel, and assessor expectations in writing so the organization does not complete an irrelevant questionnaire.
Merchants
A merchant that accepts payment cards usually has PCI DSS responsibilities even if a third-party processor or hosted checkout page is used. The scope may be smaller when the business avoids storing card data and uses validated hosted payment methods, but responsibility does not disappear.
Restaurants, retailers, ecommerce shops, healthcare offices taking payments, professional-services firms, nonprofits, hospitality businesses, and field-service companies should all understand their payment flow.
Service Providers and Vendors
Service providers can include organizations that store, process, transmit, manage, secure, support, or can affect cardholder data for another entity. An MSP, ecommerce integrator, call-center provider, payment software vendor, hosting provider, or managed firewall provider can become relevant to PCI DSS scope.
Vendor access is often ignored. Remote access, administrative accounts, backup access, logs, cloud consoles, database access, and support tools can affect the cardholder data environment even when the vendor never intends to view card data.
How to Decide
Start with a payment-flow diagram, system inventory, vendor list, and data-retention review. Then determine whether the business should complete a specific SAQ, work toward a Report on Compliance, coordinate with a QSA, obtain ASV scans, or first remediate obvious security gaps.
OC Security Audit can help prepare the technical and organizational picture before the business engages formal validation channels.
Business Roles and Evidence Patterns
Use this comparison to identify which records are likely to matter for different PCI DSS roles.
| Business type | Common PCI concern | Likely evidence |
|---|---|---|
| Retail | POS segmentation and vendor remote access | Network diagram, firewall rules, access list |
| Ecommerce | Checkout integration and web app exposure | Hosting diagram, scan results, change records |
| Restaurant | POS terminals and Wi-Fi separation | VLAN/firewall evidence, vendor list |
| Service provider | Customer CDE impact | Control descriptions, AOC, policies |
Responsibility Details That Prevent Bad Assumptions
Responsibility should be documented in writing because verbal assumptions fail during audits and incidents. A processor may secure authorization, a POS vendor may maintain the terminal, an MSP may manage the firewall, and the merchant may still own user procedures, network placement, records retention, and incident coordination.
Service providers should also be careful. Even when they never view card data, administrative access to systems that influence the CDE can create customer questions about controls, MFA, logging, vulnerability management, incident response, and evidence availability.
Responsibility follows control, access, and customer impact
A merchant remains responsible for accurately describing its environment even when a processor hosts authorization or a provider supplies terminals. The merchant controls how the service is integrated, where devices are connected, which employees use payment functions, how credentials are managed, whether data is copied into local workflows, and how providers are monitored. Outsourcing can reduce scope, but only when the architecture and shared responsibilities are understood.
A service provider should identify every service that can affect customer payment security, not only products marketed as payment services. Managed firewalls, remote monitoring and management, cloud hosting, identity administration, backup, logging, application deployment, DNS, content delivery, and support access can create customer-impacting responsibilities. The service description should state systems, personnel, locations, subcontractors, administrative methods, evidence availability, and incident notification.
Healthcare, dental, legal, nonprofit, construction, and professional-service businesses sometimes overlook PCI DSS because payment processing is not their primary industry. If they accept payment cards, the payment channel still needs review. A virtual terminal used by front-desk personnel can involve workstations, browsers, call handling, shared notes, printed records, remote support, and recurring billing even when the core business application stores only a provider token.
Validation obligations are determined through payment-brand, acquirer, customer, and contractual programs. Transaction volume may affect the reporting route, but it does not justify ignoring security. Obtain the requester instruction, map the applicable role, confirm questionnaire eligibility, and retain the reasoning. A business that is both a merchant and a technology provider may need separate scope and evidence for each role.
How PCI SSC describes merchant and service-provider responsibility
PCI DSS is intended for merchants regardless of transaction volume and for service providers that store, process, transmit, manage, secure, or can affect payment account data. Read the PCI SSC small-merchant FAQ.
Choose the next page by unresolved responsibility
Organizations with a known role but uncertain architecture should continue into scope. Organizations already answering a processor or customer should study the validation route.
PCI DSS SAQ, AOC, ROC, QSA, and ASV Validation Guide: Understand reporting forms, qualified roles, and requester expectations.
PCI DSS for Cloud, Ecommerce, POS, and Payment Applications: Map the technical exposure created by checkout, terminals, cloud, and support.
Common PCI DSS Gaps Merchants, MSPs, and IT Teams Miss: Recognize recurring responsibility gaps between merchants, MSPs, and vendors.
MSPs and vendors should also review the common-gaps casebook before accepting loosely defined control ownership. Contact OC Security Audit.
Clarify roles before attestation
Ali Hassani helps organizations connect the contractual request with the technical reality of merchant, service-provider, MSP, application, and vendor responsibilities.
Ali Hassani is a CISO, cybersecurity and IT consultant, and infrastructure leader with 25+ years of experience. His credentials include CISSP, CCISO, CCNP, CCNA, MCSE, MCSA Security, MCITP, MCP, and MCTS.