Key Takeaway: PCI DSS compliance is not your client’s problem to solve alone. If you manage IT for any business that accepts credit cards, you are part of their compliance environment. Understanding what PCI requires, what your role is, and how to help clients maintain compliance is the difference between an MSP that creates liability and one that reduces it.
PCI DSS affects more of your clients than you probably realize. Any business that accepts, processes, stores, or transmits credit card data is subject to the Payment Card Industry Data Security Standard. That includes the restaurant using a tablet POS system, the dental office billing through a payment portal, the law firm that takes retainer payments by card, and the retail shop with a card reader at the counter.
The MSP that manages IT for these businesses is part of their cardholder data environment. That creates obligations, risks, and service opportunities that most MSPs have not fully addressed.
What PCI DSS Actually Requires
PCI DSS version 4.0, which became the mandatory standard in March 2024, organizes its requirements into six goals and twelve requirement categories. The full standard runs to hundreds of pages, but the core requirements that affect MSP-managed environments are consistent and knowable.
Network security. The cardholder data environment (CDE) must be isolated from other networks using firewalls. Systems that store, process, or transmit cardholder data cannot be directly accessible from the internet. Wireless networks must be separated from the CDE. Network diagrams must be current and accurate.
No vendor-supplied defaults. Default passwords and security settings on all system components must be changed before deployment. This includes network equipment, servers, point-of-sale systems, and any other device in or connected to the CDE. Default credentials are the first thing attackers try.
Cardholder data protection. Stored cardholder data must be protected using encryption, truncation, masking, or hashing. Primary account numbers (PANs) must not be stored after authorization unless there is a documented business need. Cardholder data must not be stored in logs, debug files, or history files.
Encryption in transit. Cardholder data transmitted over open, public networks must be encrypted using strong cryptography. TLS 1.2 or higher is required. Older protocols (SSL, TLS 1.0, TLS 1.1) are prohibited in the CDE.
Malware protection. Anti-malware software must be deployed on all systems commonly affected by malware. The software must be kept current, actively running, and generating audit logs. PCI DSS 4.0 expands this to require behavioral detection capabilities, not just signature-based antivirus.
Secure systems and software. All system components must be protected from known vulnerabilities by installing applicable security patches. Critical patches must be installed within one month of release. A vulnerability management program must be in place.
Access control. Access to cardholder data must be restricted to individuals whose job requires it. Each person with computer access must have a unique ID. Physical access to cardholder data must be restricted and monitored.
Authentication. MFA is required for all access into the CDE, including remote access and administrative access. This is a significant expansion in PCI DSS 4.0 from the previous version, which required MFA only for remote access.
Physical security. Physical access to systems in the CDE must be restricted. Media containing cardholder data must be physically secured. Destruction of media must be documented.
Logging and monitoring. All access to network resources and cardholder data must be logged. Audit logs must be retained for at least 12 months, with the most recent three months available for immediate analysis. Logs must be reviewed daily for anomalies.
Security testing. Networks must be tested for vulnerabilities at least quarterly using automated scanning tools. Penetration testing must be performed at least annually and after any significant infrastructure change.
Information security policy. A security policy must be maintained, reviewed annually, and communicated to all personnel.
Merchant Levels and What They Mean
PCI DSS compliance requirements vary by merchant level, which is determined by transaction volume.
Level 1 merchants process more than 6 million Visa or Mastercard transactions annually. They require an annual on-site assessment by a Qualified Security Assessor (QSA) and quarterly network scans by an Approved Scanning Vendor (ASV). Most of your SMB clients are not Level 1.
Level 2 merchants process 1 to 6 million transactions annually. They require an annual Self-Assessment Questionnaire (SAQ) and quarterly ASV scans.
Level 3 merchants process 20,000 to 1 million e-commerce transactions annually. They require an annual SAQ and quarterly ASV scans.
Level 4 merchants process fewer than 20,000 e-commerce transactions or up to 1 million other transactions annually. They require an annual SAQ and quarterly ASV scans. Most of your SMB clients fall here.
The Self-Assessment Questionnaire is a self-certification document. There are multiple SAQ types depending on how the merchant processes payments. The SAQ type determines which requirements apply. An MSP that helps clients identify the correct SAQ type and complete it accurately is delivering compliance advisory value.
The MSP’s Role in PCI Compliance
If you manage any system that is in scope for PCI DSS, you are a service provider under the standard. PCI DSS Requirement 12.8 requires covered entities to maintain a list of all service providers with access to cardholder data, have a written agreement with each that includes an acknowledgment of their responsibility for the security of cardholder data, and monitor service providers’ PCI DSS compliance status annually.
This means your clients should have a written agreement with you that specifies your PCI-related responsibilities. It means you should be able to demonstrate your own compliance with the requirements that apply to your services. And it means your clients are responsible for verifying that you are compliant.
The MSP that has not thought about its PCI obligations is creating risk for itself and its clients. The MSP that has documented its PCI responsibilities, maintains the required controls, and can provide clients with evidence of compliance is a more defensible service provider.
Scope Reduction: The Most Valuable PCI Service
The most effective PCI compliance strategy for SMB clients is scope reduction. The fewer systems that touch cardholder data, the fewer systems that need to meet PCI requirements. The most common scope reduction approach is point-to-point encryption (P2PE) combined with a hosted payment page.
With P2PE, cardholder data is encrypted at the point of swipe and never enters the merchant’s network in readable form. The merchant’s systems never see the PAN. This dramatically reduces the scope of the PCI assessment and simplifies compliance significantly.
With a hosted payment page, the payment form is hosted by the payment processor rather than the merchant’s website. Cardholder data goes directly to the processor and never touches the merchant’s servers. Again, scope is dramatically reduced.
Helping clients implement P2PE and hosted payment pages is a service that reduces their compliance burden, reduces their breach risk, and reduces your exposure as their MSP. It is also a conversation that most clients have never had with their IT provider.
Common PCI Failures in MSP-Managed Environments
Default credentials on network equipment. The firewall installed three years ago with the default admin password. The wireless access point with the default SSID and password. These are PCI violations and security vulnerabilities simultaneously.
Flat networks. The client whose POS system is on the same network as the office computers, the guest WiFi, and the security cameras. PCI requires network segmentation between the CDE and other systems. A flat network means everything is in scope.
Outdated software. The POS system running Windows 7 because the vendor has not released a Windows 11 compatible version. The payment application that has not been updated in two years. End-of-life operating systems and unpatched software are PCI violations.
No log review. Logs are being generated but nobody is reviewing them. PCI requires daily log review. This is where a SIEM or managed log review service becomes a compliance requirement, not just a security best practice.
Missing MFA. PCI DSS 4.0 requires MFA for all access into the CDE. Many environments that were compliant under PCI DSS 3.2.1 are not compliant under 4.0 because MFA was not required for all CDE access previously.
Frequently Asked Questions
Does PCI DSS apply to my client if they use Square or Stripe?
Yes, but scope may be significantly reduced. Using a payment processor that handles all cardholder data through their own systems (hosted payment pages, P2PE terminals) reduces the merchant’s PCI scope dramatically. The merchant still has PCI obligations, but they are much simpler to meet. The SAQ type will be shorter and the requirements fewer.
What happens if a client fails a PCI audit or has a breach?
Non-compliant merchants who experience a breach face fines from the card brands (Visa, Mastercard) ranging from $5,000 to $100,000 per month, potential loss of the ability to accept card payments, and liability for fraud losses. The fines are assessed by the acquiring bank, which passes them to the merchant. The MSP that managed the non-compliant environment may face contractual liability depending on the service agreement.
How often do clients need to complete the SAQ?
Annually. Quarterly ASV scans are also required for most merchant levels. The SAQ and scan results are submitted to the acquiring bank (the bank that processes the merchant’s card transactions).
What is an ASV scan?
An Approved Scanning Vendor scan is an external vulnerability scan of the merchant’s internet-facing systems performed by a PCI-approved vendor. It checks for known vulnerabilities that could be exploited to access cardholder data. The scan must pass (no high-severity vulnerabilities) before the merchant can certify compliance.
Should I offer PCI compliance as a managed service?
Yes, if you serve clients who accept card payments. The service includes helping clients identify their SAQ type, completing the SAQ accurately, managing quarterly ASV scans, maintaining the required controls, and providing evidence of compliance. This is a recurring revenue service that clients need annually and cannot easily do themselves.
Sources
- PCI Security Standards Council Document Library
- PCI DSS Quick Reference Guide
- Visa Global Registry of Service Providers
Related Reading: Cyber Insurance Requirements 2026 | HIPAA for MSPs | GRC as a Service | MSP Incident Response Plan | MSP Cybersecurity Hub
