The Payment Card Industry Data Security Standard (PCI-DSS) governs the security of cardholder data environments for any organization that stores, processes, or transmits payment card data. Version 4.0, which became the only active version as of March 31, 2024, introduced significant new requirements around authentication, web application security, and targeted risk analysis. For MSPs, PCI-DSS matters in two ways: your clients who handle card payments must comply, and if you manage their network or infrastructure, you are a service provider in scope. This guide covers who PCI applies to, what changed in v4.0, all 12 requirements, SAQ types, CDE scoping, and how Gridlock automates PCI monitoring.
PCI-DSS v3.2.1 was officially retired on March 31, 2024. All assessments must now be conducted against v4.0. If your clients have assessments or SAQs based on v3.2.1 from before April 2024, they need to be re-evaluated against v4.0 requirements. Several "best practice" items from v3.2.1 became mandatory requirements in v4.0.
PCI-DSS applies to any entity that stores, processes, or transmits cardholder data — or that could impact the security of the cardholder data environment. This is broader than most organizations realize, and MSPs frequently fall in scope without recognizing it.
Any business that accepts payment cards as payment for goods or services is a merchant. Merchants are classified into four levels based on annual transaction volume, which determines the validation requirements (SAQ vs. on-site assessment) and the scrutiny applied by acquiring banks.
A service provider is any business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. Service providers are also divided into two levels. Critically, if a service provider can affect the security of the cardholder data environment — even if they never directly touch card data — they may still be in scope.
Most MSPs are PCI service providers if they do any of the following for merchant clients:
PCI-DSS scoping rules include systems that are "connected to" or "that could impact" the CDE — not just systems that directly handle card data. An MSP's management platform that can push agents to CDE servers, a jump host with access to the CDE network, or a shared log collector that ingests CDE events are all potentially in scope. Work with your clients' QSA to conduct a formal scope boundary determination before assuming you are out of scope.
PCI-DSS is not law — it is a contractual requirement enforced by the payment brands (Visa, Mastercard, American Express, Discover, JCB) through their networks and acquiring banks. Non-compliance is enforced through fines assessed to the merchant's acquiring bank, which are passed on to the merchant. The card brands also have the ultimate authority to suspend a merchant's ability to accept their cards.
PCI-DSS v4.0 introduced 64 new requirements and significantly updated dozens of existing ones. The changes reflect the evolving threat landscape, the move to cloud and e-commerce environments, and the recognition that prescriptive controls alone are insufficient. Here are the most impactful changes for MSPs and their clients.
v4.0 introduced a "Customized Approach" alongside the traditional "Defined Approach." Under the Customized Approach, entities can implement controls that differ from the defined requirement but achieve the same security objective. This requires a QSA (Qualified Security Assessor) to validate the custom control — it is not self-attested. Most small and mid-size merchants will continue to use the Defined Approach.
Multiple v4.0 requirements allow organizations to use a targeted risk analysis to determine the frequency of performing certain activities (e.g., how often to review firewall rules, user access reviews). This is a significant change from the prescriptive annual or quarterly timelines in v3.2.1 — but it requires documented risk analysis to justify the chosen frequency. Gridlock generates the supporting risk evidence for these analyses automatically.
| Requirement | Change | Impact for MSPs |
|---|---|---|
| Req. 2.2.7 | All non-console administrative access must use cryptography. Telnet and HTTP admin interfaces are prohibited. Required | Audit all out-of-band management interfaces on CDE systems. RDP without encryption, web-based admin panels over HTTP, and telnet management all need to be eliminated. |
| Req. 5.3.3 | Anti-malware solutions on removable electronic media must perform scans on insertion/connection. New | Verify endpoint protection on CDE systems is configured to scan USB and removable media on connect — not just on-demand or scheduled. |
| Req. 6.4.3 / 11.6.1 | Payment page scripts must be managed with an inventory and integrity mechanism. Changes to HTTP headers and payment page scripts must be detected. New | E-commerce clients need Content Security Policy (CSP) headers and script integrity monitoring on payment pages. Gridlock monitors HTTP security headers and can alert on unauthorized changes. |
| Req. 8.3.6 | Passwords must be a minimum of 12 characters (up from 8 in v3.2.1) if passwords are used as authentication factors. Required | Review password policy on all CDE system accounts. Active Directory, local accounts, and service accounts all need to be audited and updated. |
| Req. 8.4.2 | MFA is required for all access into the CDE — not just remote access. Required | In v3.2.1, MFA was only required for remote access. v4.0 extends this to all non-console CDE access, including admin sessions from inside the network. This is a major implementation change for most clients. |
| Req. 10.7.2 | Failures of critical security controls must be detected, alerted upon, and responded to promptly. New | Security control failure detection — firewalls going offline, IDS stopping, anti-malware disabled — must generate immediate alerts. Gridlock monitors security control health and generates alerts on failures. |
| Req. 12.3.2 | A targeted risk analysis must be performed for any PCI requirement with a "defined frequency" option, to determine the appropriate activity frequency. New | Multiple requirements now have flexible frequencies driven by risk analysis rather than fixed calendar intervals. You need documented risk justification for the chosen frequency — Gridlock generates supporting risk data. |
| Req. 12.9.2 | Service providers must support customers' requests to confirm that the service provider protects customer data and maintains applicable PCI requirements. New | MSPs acting as service providers now have a formal obligation to respond to client PCI compliance inquiries. Gridlock's service provider compliance reporting package satisfies this requirement. |
PCI-DSS v4.0 is organized into 12 principal requirements, grouped into six goals. The 12 requirements contain a total of over 300 sub-requirements. Below is an overview of each requirement and its primary security objective.
Install and maintain network security controls to protect the CDE. Firewalls, routers, and network segmentation. Rule review every 6 months (or via risk analysis).
Apply secure configurations to all system components. Eliminate vendor defaults. Maintain configuration standards inventory. Non-console admin requires encryption.
Minimize cardholder data retention. Never store sensitive authentication data (CVV, PIN, magnetic stripe) after authorization. Encrypt stored PANs.
Encrypt cardholder data transmission over public networks. TLS 1.2 minimum (TLS 1.3 preferred). No use of SSL, TLS 1.0, or TLS 1.1.
Deploy and maintain anti-malware on all system components. Periodic evaluations for systems not commonly affected by malware. Scan removable media on insertion.
Identify and address security vulnerabilities. Secure development practices. Protect web-facing applications. Monitor payment page scripts for unauthorized changes.
Limit access to system components and cardholder data to only individuals whose job requires such access. Document and enforce least-privilege access model.
Unique IDs for all users. MFA for all CDE access. 12-character minimum passwords. Prohibit shared credentials. Account management including termination procedures.
Restrict physical access to CDE systems. Physically secure POI devices (card readers). Visitor logs. Media disposal procedures. Device inventory.
Implement audit logging on all CDE system components. Protect logs from destruction. Review logs daily. Detect security control failures promptly.
Quarterly vulnerability scans (internal and external). Annual penetration test. File integrity monitoring. Detect unauthorized wireless. Monitor payment page scripts.
Maintain information security policies. Risk analysis. Security awareness training. Vendor management. Incident response plan. Service provider agreements.
Several requirements are especially relevant to MSPs managing CDE environments. Here is additional detail on the highest-stakes ones.
Every CDE must have a documented network diagram showing all data flows for cardholder data. Firewall and router rules must be reviewed at least every 6 months (or per a documented risk analysis). Rules must be documented with business justification. Inbound connections to the CDE must be explicitly permitted — default deny. MSPs managing network infrastructure for PCI clients must maintain:
This is the most impactful change from v3.2.1 to v4.0 for most organizations. Under v4.0, MFA is required for all access into the CDE — not just remote access. This means:
PCI requires audit logs from all CDE system components, reviewed at least daily. "Daily review" is often the hardest requirement for small organizations to meet without automation. Gridlock's log aggregation and automated anomaly alerting satisfies the intent of daily review — alerts surface the events requiring human attention without requiring manual inspection of every log line.
Required events to log under PCI-DSS v4.0:
Self-Assessment Questionnaires (SAQs) are validation tools for merchants and service providers that do not require an on-site assessment by a QSA. Different SAQ types apply based on how an organization accepts card payments. Choosing the wrong SAQ type — or using an SAQ when a full QSA assessment is required — can result in invalidated compliance status and increased liability in the event of a breach.
| SAQ Type | Who It Applies To | Cardholder Data Environment Description | Number of Questions (v4.0) |
|---|---|---|---|
| SAQ A | Card-not-present (e-commerce) merchants who have fully outsourced cardholder data functions to PCI-compliant third parties | No electronic cardholder data storage, processing, or transmission on the merchant's premises or systems. All processing done by a PCI-compliant third party. The merchant's website does not receive cardholder data (e.g., iframe or redirect to payment page). | ~22 questions (plus new script monitoring requirements in v4.0) |
| SAQ B | Merchants using only imprint machines or standalone, dial-out terminals (no electronic storage of cardholder data) | Paper-based imprint or dial-out terminal only. No IP connectivity for card processing. No electronic cardholder data storage. | ~41 questions |
| SAQ B-IP | Merchants using only standalone, PTS-approved IP-connected POI devices | IP-connected but PTS-approved point-of-interaction devices. Devices use point-to-point encryption (P2PE). No electronic cardholder data storage. Devices not connected to other systems or internet within the same network. | ~83 questions |
| SAQ C | Merchants with payment application systems connected to the internet, but no electronic cardholder data storage | Payment application system on a single machine connected to the internet (e.g., a POS terminal with internet connectivity). No cardholder data stored electronically after authorization. | ~161 questions |
| SAQ C-VT | Merchants using web-based virtual terminals on an isolated computer | Access to cardholder data via a web-based virtual terminal on a system isolated from all other systems. No electronic cardholder data storage. | ~131 questions |
| SAQ D (Merchants) | All merchants not eligible for SAQ A, B, B-IP, C, or C-VT | Merchants that store cardholder data electronically, have multiple systems in the CDE, or have complex environments. Includes all merchant types with electronic storage. | ~329 questions |
| SAQ D (Service Providers) | All service providers eligible to complete an SAQ (Level 2 service providers) | Service providers that store, process, or transmit cardholder data, or manage components that could impact the security of the CDE for merchants. | ~329 questions |
SAQ A eligibility in v4.0 is more restrictive than in v3.2.1. Merchants using SAQ A must now implement script monitoring to detect unauthorized changes to their checkout pages (Req. 11.6.1) and maintain an inventory of all scripts loaded on their payment pages (Req. 6.4.3). Even merchants that redirect to a third-party payment page must implement these controls because malicious scripts can be injected on the pre-redirect checkout page to capture card data before the redirect occurs.
Level 1 merchants process more than 6 million transactions per year (Visa/Mastercard) or have suffered a data breach. They must have an annual on-site assessment by a QSA and a quarterly network scan by an Approved Scanning Vendor (ASV). MSPs supporting Level 1 merchants will have their environments scrutinized directly by the QSA as part of the scope determination.
Scoping the CDE correctly is the most important — and most frequently mishandled — step in PCI compliance. Errors in scoping can mean either including too much (unnecessary compliance burden) or too little (actual card data at risk outside the formal CDE).
Any system component that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD) is in the CDE and in scope for PCI. Additionally, any system component that is connected to the CDE and could impact its security is also in scope. PCI-DSS v4.0 uses three categories:
Network segmentation, when properly implemented and tested, is the most powerful tool for reducing PCI scope. A system is out of scope only if it has no connectivity to the CDE AND no ability to affect the security of the CDE. The QSA must validate segmentation. Gridlock tests segmentation controls continuously and generates evidence reports showing which systems have no permitted network paths to CDE systems.
Effective segmentation requires:
Gridlock's Compliance Agent addresses the continuous monitoring requirements of PCI-DSS v4.0 across all 12 requirements. The most labor-intensive PCI obligations — daily log review, quarterly vulnerability scanning, firewall rule review, change detection, and control health monitoring — are all automated.
Traditional PCI compliance is a quarterly event — scan, review, fix, repeat. With Gridlock, PCI monitoring runs continuously. Gaps surface in real time, not at scan time. When your quarterly ASV scan runs, there are no surprises because Gridlock has been watching the entire time.
| PCI Requirement | Gridlock Automation |
|---|---|
| Req. 1 — Network Security Controls | Maintains live network diagram with CDE boundary mapping. Analyzes firewall ruleset for any-any rules, overly permissive rules, and undocumented rules. Alerts on firewall rule changes within minutes. Generates semi-annual ruleset review evidence automatically. |
| Req. 2 — Secure Configurations | Compares CDE system configurations against PCI-aligned security baselines (CIS Benchmarks). Detects vendor default credentials. Alerts on non-encrypted management access (telnet, HTTP admin). Tracks configuration drift from approved baseline. |
| Req. 3 — Protect Stored Account Data | Scans for unencrypted PANs in databases, file systems, and log files across the CDE. Detects CVV/SAD storage violations. Verifies encryption on all identified cardholder data stores. Tracks PAN masking compliance in application outputs. |
| Req. 4 — Protect Data in Transit | Monitors TLS version and cipher suite configuration on all CDE network services. Alerts on SSL, TLS 1.0, and TLS 1.1 usage. Detects unencrypted cardholder data flows on the network. Certificate expiration monitoring with advance warning. |
| Req. 5 — Protect from Malicious Software | Monitors anti-malware deployment, update status, and scanning configuration on all CDE systems. Alerts when anti-malware is disabled, outdated by more than 24 hours, or not configured to scan removable media on insertion. |
| Req. 6 — Secure Systems and Software | Vulnerability inventory for all CDE systems with CVSS scoring and remediation SLA tracking. Monitors HTTP security headers on payment pages (Content-Security-Policy, Subresource Integrity). Script inventory and change detection for payment pages. |
| Req. 7 — Restrict Access | Continuous least-privilege access review for CDE systems. Detects over-provisioned accounts, inactive accounts with access, and accounts with more access than their role requires. Generates access review evidence for QSA. |
| Req. 8 — Identify and Authenticate | Monitors MFA enforcement on all CDE access paths. Audits password policy compliance (12-character minimum, complexity, history). Detects shared credentials and generic accounts. Tracks failed authentication attempts and lockout policy compliance. |
| Req. 10 — Log and Monitor | Centralizes and normalizes log collection from all CDE systems. Automated anomaly detection and alert triage replaces manual daily review obligation. Tamper-evident log storage. Log retention tracking (12-month minimum with 3-month online/searchable). Security control failure detection (Req. 10.7.2). |
| Req. 11 — Test Security | Schedules and tracks internal vulnerability scans (quarterly). Coordinates with ASV for external scans. File Integrity Monitoring (FIM) on all CDE system binaries, configuration files, and log files. Rogue wireless access point detection. Payment page script change detection (Req. 11.6.1). |
| Req. 12 — Support Information Security | Tracks policy review dates and generates reminders. Maintains incident response plan version control. Service provider agreement tracking. Risk analysis documentation support. Security awareness training completion monitoring. |
Network segmentation is the single most impactful lever for reducing a client's PCI compliance burden. Proper segmentation can reduce the CDE from an entire corporate network to a small, isolated zone — shrinking the number of systems in scope from hundreds to dozens. This is one of the highest-value services an MSP can deliver for a merchant client.
Gridlock documents and monitors three common CDE segmentation architectures for MSP clients:
All CDE systems placed on a dedicated VLAN with firewall rules blocking all traffic except what is explicitly required for business operations. The firewall is the sole connection between CDE and non-CDE networks. This is the most common pattern for small merchants with self-hosted POS systems.
CDE systems placed in a DMZ with two firewall tiers — one facing the internet and one facing the internal network. Commonly used for e-commerce environments where web application servers need internet-facing connectivity but cardholder data processing happens on back-end servers with no direct internet access.
The most effective scope reduction strategy: point-to-point encryption (P2PE) or tokenization eliminates cardholder data from the merchant's network entirely. Card data is encrypted at the point of interaction and decrypted only at the payment processor. Combined with a qualified P2PE solution, merchants may qualify for SAQ P2PE — which has dramatically fewer questions than SAQ D. MSPs can advise clients on P2PE solutions and implement the network infrastructure to support them.
Many small businesses have flat networks with no segmentation — all devices, including POS terminals, on the same network as workstations, printers, and guest WiFi. Every device on that network is in PCI scope. Implementing proper segmentation for these clients is often the single highest-value PCI service an MSP can provide, immediately reducing scope and compliance burden for the client.
PCI-DSS requires quarterly vulnerability scanning for CDE systems from both internal and external perspectives. These are distinct scan types with different requirements, tools, and evidence formats.
External quarterly scans must be performed by a PCI SSC Approved Scanning Vendor (ASV). ASV scans target internet-facing IP addresses and hostnames associated with the CDE from the outside in. Requirements:
Gridlock integrates with leading ASV providers to track scan scheduling, ingest results, map findings to the CDE asset inventory, and generate remediation tickets with priority ranking. Scan history is stored in the compliance evidence repository accessible during QSA assessments.
Internal scans must cover all CDE systems from an internal perspective. Unlike ASV scans, internal scans do not need to be performed by an ASV — they can be performed by qualified internal staff or by Gridlock's built-in scanning capabilities. Requirements:
Annual penetration testing is required for all entities in scope for PCI-DSS (except those using approved P2PE solutions for all card processing). The penetration test must:
| Scanning Type | Gridlock Capability |
|---|---|
| Internal quarterly scans | Built-in vulnerability scanner scheduled automatically every 90 days (or more frequently per risk analysis). Results auto-ingested into compliance evidence store. CDE assets automatically targeted based on scope configuration. |
| External ASV scans | Gridlock integrates with ASV providers to track scan schedules and import results. Alerts when next scan window is approaching. Tracks passing/failing status and re-scan dates. |
| Penetration test tracking | Tracks pentest scheduling, scope documents, findings, remediation status, and retests. Maintains evidence archive for QSA review. Sends advance reminders when next test is due. |
| Post-change scans | Detects significant CDE changes (new systems, configuration changes, firewall rule updates) and automatically triggers scan scheduling workflow to ensure post-change scan requirements are met. |
PCI-DSS penalties are not assessed by a government agency — they are contractual fines imposed by card brands (Visa, Mastercard, Amex) on acquiring banks, which pass them to merchants. The penalty structure is based on merchant level and the circumstances of non-compliance or breach. Penalties escalate significantly in the event of a breach.
| Level | Transaction Volume (Visa) | Validation Requirement | Annual Assessment |
|---|---|---|---|
| Level 1 | Over 6 million Visa transactions/year, OR any merchant that has suffered a data breach | Annual on-site assessment by a QSA. Quarterly network scan by ASV. Annual penetration test. | On-site QSA (most rigorous) |
| Level 2 | 1–6 million Visa transactions/year | Annual SAQ. Quarterly network scan by ASV. | SAQ D (merchant) |
| Level 3 | 20,000–1 million e-commerce Visa transactions/year | Annual SAQ. Quarterly network scan by ASV. | SAQ A or SAQ D depending on environment |
| Level 4 | Fewer than 20,000 e-commerce OR up to 1 million other Visa transactions/year | Annual SAQ. Quarterly network scan recommended by Visa (some acquiring banks require it). | SAQ A, B, C, or D depending on environment |
Monthly fines from acquiring banks for failure to demonstrate compliance status. Applied until compliance is validated.
Initial fines following a breach investigation where compliance was absent. Additional assessments typically imposed.
Fines for significant breaches with widespread cardholder impact. Forensic investigation costs borne by merchant.
Card brands may increase interchange rates for non-compliant merchants on each transaction — ongoing financial penalty beyond fines.
For merchants who suffer a significant breach and cannot demonstrate remediation, card brands retain the right to terminate processing privileges entirely. A merchant that cannot accept Visa or Mastercard is functionally out of business for most retail categories. MSPs should communicate this to clients framing PCI compliance as a business continuity investment, not just a checkbox exercise.
In the event of a breach, card brands require the merchant to hire a PCI Forensic Investigator (PFI) to conduct a forensic investigation. PFI costs are borne entirely by the merchant and typically range from $20,000 to over $100,000 depending on scope. Card brands also assess costs for the card reissuance programs triggered by compromised card numbers — these can reach hundreds of thousands of dollars for large breaches.
Use this checklist to assess a client's PCI-DSS posture or to prepare for a QSA assessment. Items are organized by the 12 requirements.
A well-managed PCI environment has: a clearly defined and minimized CDE backed by tested segmentation; continuous monitoring through Gridlock covering all 12 requirements; current quarterly scan results (passing); an annual penetration test with all findings remediated; and a tested incident response plan. QSA assessments of properly managed Gridlock-monitored environments produce dramatically fewer findings and faster completion times because the evidence is pre-organized and continuously maintained.
The AI agent powering PCI monitoring — CDE scoping, evidence collection, and scan scheduling automation.
NIST CSF provides the risk management overlay that complements PCI-DSS technical requirements.
Technology service providers handling cardholder data often need both PCI and SOC 2 Type II.
Healthcare merchants that accept payments face both HIPAA and PCI-DSS simultaneously — see how to manage both.