Merchants: your clients
Any business that accepts payment cards: retail, restaurants, professional offices, e-commerce, nonprofits taking donations. Every one of them must validate PCI DSS compliance annually to their acquirer, whatever their size.
PCI DSS Field Guide for MSPs
PCI DSS compliance, made operational: the MSP's tactical playbook
A tactical playbook for managed service providers guiding merchant clients through the 12 requirements, scoping the cardholder data environment, and choosing the right SAQ, with a step-by-step ControlMap workflow for assessments, controls, policies, and evidence.
Start Here
PCI DSS at a glance: why it lands on the MSP's desk
The Payment Card Industry Data Security Standard (PCI DSS) is the global security standard for protecting payment card data, maintained by the PCI Security Standards Council and enforced contractually through the card brands and acquiring banks. Unlike HIPAA, it isn't a law, but non-compliance carries fines, higher processing fees, forensic-investigation costs, and ultimately the loss of the ability to take cards. If your MSP manages systems that store, process, or transmit card data, or could affect their security, you're in scope too.
Two Roles, Both Obligated
Service providers: that's you
Entities that store, process, or transmit cardholder data on behalf of others, or that can impact its security, hosting providers, managed firewall/IT providers, backup operators. An MSP with admin access to a merchant's network typically qualifies, and clients will ask for your own attestation.
What You're Protecting
Account data: two classes
The cardholder data environment (CDE) is the people, processes, and technology that store, process, or transmit account data, plus every system connected to it or able to affect its security. The size of the CDE determines the size of the compliance effort.
Cardholder data (CHD)
PAN (the card number) plus cardholder name, expiry, and service code. May be stored only if needed, and then PAN must be rendered unreadable (strong encryption, truncation, tokenization) and masked when displayed.
Sensitive authentication data (SAD)
Full track data, CVV/CVC security codes, PINs/PIN blocks. Never storable after authorization, not in databases, logs, call recordings, scans, or spreadsheets. Finding SAD at rest is an automatic red-alert finding.
Why it matters: after a card-data breach, acquirers can pass through brand assessments and monthly non-compliance fines, mandate a PCI Forensic Investigator (PFI) engagement at the merchant's expense, force re-validation at a higher level, and raise rates, on top of card-reissuance costs and lawsuits. For a small practice or shop, the existential risk isn't the fine; it's losing the ability to accept cards at all.
01
The Baseline
The standard: 6 goals, 12 requirements
PCI DSS establishes a baseline of technical and operational controls protecting account data, applied to every system in or connected to the CDE. PCI DSS v4 organizes the 12 requirements under six security goals: the grouped rows below, and lets entities meet them via the prescriptive defined approach or an outcome-based customized approach for mature environments, contrasted just after.
Goal by Goal
Requirements 1–12: build, protect, patch, control, watch, and govern
| Goal | Requirement | What it demands in practice | MSP translation |
|---|---|---|---|
| Build & maintain secure networksReq 1–2 | 1 · Install & maintain network security controls | Firewalls/NSCs between untrusted networks and the CDE; documented rulesets reviewed at least every 6 months; restrict inbound/outbound traffic to what's necessary; control connections from wireless and third parties. | Managed firewall with documented, ticketed rule changes and semi-annual ruleset reviews. |
| 2 · Apply secure configurations | No vendor defaults anywhere: change default passwords/SNMP strings, remove unneeded services and accounts, harden to standards (e.g., CIS benchmarks), one primary function per server, inventory all components. | Golden images, hardening baselines in RMM, configuration drift alerts. | |
| Protect account dataReq 3–4 | 3 · Protect stored account data | Keep storage to a documented minimum with retention/disposal schedules; never store SAD post-authorization; mask PAN on display (BIN + last four max); render stored PAN unreadable via strong cryptography, truncation, or tokens; manage keys formally. | Data-discovery scans for PAN in file shares/email; tokenization via the payment processor; key custodian procedures. |
| 4 · Strong cryptography in transmission | Encrypt PAN over open/public networks with strong TLS; never send PAN via unprotected email, chat, or SMS; inventory certificates and trusted keys. | TLS policy enforcement, secure email/file-transfer tooling, cert lifecycle monitoring. | |
| Vulnerability managementReq 5–6 | 5 · Protect systems from malware | Anti-malware on all systems commonly affected; keep it current, running, and tamper-proof; periodic scans or continuous behavioral analysis; address phishing (technical anti-phishing controls in v4). | EDR/MDR deployed via RMM with tamper protection and reporting; email security gateway. |
| 6 · Develop & maintain secure systems and software | Identify and risk-rank vulnerabilities; patch critical fixes within one month; secure development practices for custom code; change control; inventory and manage payment-page scripts on e-commerce sites (v4). | Patch SLAs in the RMM, change-management tickets, script integrity monitoring for checkout pages. | |
| Strong access controlReq 7–9 | 7 · Restrict access by need to know | Role-based access to CDE systems and card data; default deny; documented approval for privileges; review all access at least every 6 months. | RBAC matrix per client, semi-annual access reviews exported as evidence. |
| 8 · Identify users & authenticate access | Unique IDs for every user, no shared accounts; strong password rules (12+ chars in v4); MFA for all access into the CDE and all remote access; lock-out and session controls; manage vendor accounts tightly. | MFA everywhere via identity platform; conditional access; disable-on-termination runbook. | |
| 9 · Restrict physical access | Control entry to areas with card data systems; visitor handling; secure media storage and destruction; inspect POS terminals for tampering/skimmers and train staff to spot them. | Terminal inspection checklist + photo log; locked racks; media destruction certificates. | |
| Monitor & testReq 10–11 | 10 · Log & monitor all access | Audit logs on all CDE components capturing access to card data and admin actions; synchronized time; protect logs; daily review (automated in v4); retain 12 months, 3 months readily available. | SIEM/log management with alert-driven review and 12-month retention per client. |
| 11 · Test security regularly | Quarterly internal vulnerability scans and quarterly ASV external scans; annual penetration testing with segmentation validation; wireless scans; change-and-tamper detection on payment pages (v4). | Scheduled scan calendar; ASV vendor management; remediation-to-rescan workflow. | |
| Information security policyReq 12 | 12 · Org-wide security program | Maintained security policy; acceptable-use rules; risk analyses; annual security awareness training; vendor/service-provider management with responsibility matrices (12.8/12.9); tested incident response plan; quarterly scope confirmation for service providers. | Policy library, training campaigns, vendor register, and IR tabletop, all evidenced. |
Spotlight · Requirement 3
Storage rules at a glance
OK · PAN: storable if justified
…but only unreadable: strong encryption, truncation, or tokenization, with documented retention and quarterly purge checks.
MINIMIZE · Name · expiry · service code
Storable with normal protection, but still minimize; they're only sensitive alongside PAN.
NEVER · CVV · track data · PIN
Never after authorization, and watch the hiding places: call recordings, ticket notes, scanned order forms, debug logs.
Translate it to your MSP stack: managed firewall → Req 1 · hardening baselines → Req 2 · tokenization with the processor → Req 3 · TLS + secure mail → Req 4 · EDR/MDR → Req 5 · patch SLAs → Req 6 · RBAC + access reviews → Req 7 · MFA everywhere → Req 8 · terminal inspections → Req 9 · SIEM/log management → Req 10 · scans + pen-test program → Req 11 · policies + training + IR → Req 12.
Who Does What
Requirements responsibility split
Typical allocation across the 12 requirements for an MSP-supported merchant: the responsibility matrix records the real split per client.
Network, configs, patching, malwareReq 1–2, 5–6
MSP
Shared
Client
Data storage & crypto decisionsReq 3–4
MSP
Shared
Client
Access, identity & MFAReq 7–8
MSP
Shared
Client
Physical security & terminal inspectionsReq 9
MSP
Shared
Client
Logging, scanning & testingReq 10–11
MSP
Shared
Client
Policies, training, vendors, IRReq 12
MSP
Shared
Client
MSP leadsSharedClient leadsProportions measured from the source guide's chart: the responsibility matrix records the real allocation per client.
Defined or customized: two ways to meet every requirement
Defined approach
Follow the stated requirement and testing procedure as written: the prescriptive path. The right default for SMB merchants and nearly every SAQ engagement: predictable to implement, predictable to evidence, and the approach the standard self-assessment forms are built around.
Customized approach
Meet the requirement's objective a different way, outcome-based, with a documented risk analysis and QSA testing of the alternative control. Built for mature organizations with security engineering depth; not available on standard SAQs, so it stays the exception in an MSP's merchant book.
MSP tip: v4 added future-dated requirements that became mandatory March 31, 2025, including broader MFA, payment-page script controls, and automated log review. If a client validated under v3.2.1 thinking, re-baseline them.
02
Scope First, Choose Second
Scope the CDE, then choose the SAQ
The Self-Assessment Questionnaire (SAQ) is how most SMB merchants validate compliance, a question set matched to how they accept cards. The smaller and simpler the cardholder data environment, the shorter the SAQ. Scope first, choose second: picking the wrong SAQ can void the client's compliance entirely.
Four Scope-Reduction Levers: Pull These Before Assessing Anything
Outsource the payment page
Hosted redirect or iframe from a compliant processor keeps card data off the client's site: the SAQ A path.
Validated P2PE terminals
PCI-listed point-to-point encryption means the merchant network never sees clear card data: the SAQ P2PE path.
Tokenize stored data
Replace stored PANs with processor tokens for recurring billing, electronic card storage is what forces SAQ D.
Segment the network
Isolate payment systems from the office LAN, guest Wi-Fi, and IoT, out-of-scope systems don't get assessed.
Before choosing, document
Network topology, card data flow diagrams for every acceptance channel, and a system inventory. They're how you prove scoping was done correctly, and they make SAQ selection obvious.
One SAQ per channel
Assess each acceptance channel separately, e-commerce, mail/telephone order (MOTO), and card-present. A client might validate SAQ A online + P2PE in store, which is far lighter than one SAQ D covering everything.
Eligibility is strict
When a client doesn't meet every criterion for the SAQ they want, the fallback is SAQ D. When in doubt, confirm with the acquirer or a QSA before promising a short path.
The SAQ Family
Nine forms, one decision
Effort ranges from a couple dozen questions (SAQ A, P2PE) to several hundred (SAQ D), exact counts vary by standard version, but the ordering below holds. Every SAQ pairs with a signed Attestation of Compliance (AOC).
| SAQ | Eligibility in plain language | Channels | Effort |
|---|---|---|---|
| A | Card-not-present only, with all account data functions fully outsourced to compliant providers, e-commerce via full redirect or iframe; no electronic storage, processing, or transmission on the merchant's systems. | E-commerce · MOTO | Light |
| A-EP | E-commerce where payment processing is outsourced but the merchant's website affects the transaction's security, e.g., it serves the payment form or scripts (direct post / JavaScript methods). | E-commerce only | Heavy |
| B | Imprint machines or standalone dial-out terminals only, no internet connection, no electronic storage. | Card-present · MOTO | Light |
| B-IP | Standalone, PCI PTS-approved terminals connecting to the processor over IP, segmented from other systems, no electronic storage. | Card-present · MOTO | Moderate |
| C | Payment application systems (e.g., POS software) connected to the internet, no electronic card storage, system isolated per the eligibility criteria. | Card-present · MOTO | Heavy |
| C-VT | Cards keyed one-at-a-time into a web-based virtual terminal from an isolated workstation, no card-reading hardware, no electronic storage. | Card-present · MOTO | Moderate |
| P2PE | Hardware terminals operated within a PCI-listed P2PE solution, clear-text card data never touches merchant systems; no electronic storage. | Card-present · MOTO | Light |
| DMerchant | Everyone who doesn't fit a lighter form, including anyone who stores account data electronically or uses API-integrated e-commerce. | All channels | Extensive |
| DService Provider | SAQ-eligible service providers (lower-volume SPs; high-volume SPs need a QSA Report on Compliance). The form your MSP will most likely face. | All channels | Extensive |
Rule of thumb: the further card data stays from client-owned systems, the lighter the SAQ. SAQ A and P2PE are the destinations; A-EP, C, and D are what clients drift into by accident, usually via a developer "just adding a payment form" or someone saving card numbers in a spreadsheet. Also in the family: SPoC/MPoC solutions (phone-as-terminal) have their own listings, verify they're PCI-validated before a client adopts them. And an organization can be a merchant and a service provider at once, validating each role separately.
Ask This First
Does the client store account data electronically: anywhere?
Yes: anywhere→ Stop searching, it's SAQ D, or remediate the storage first. Legacy systems, exports, and call recordings all count.
No→ Continue below, once per acceptance channel, e-commerce, mail/telephone order, and card-present each get their own walk-through.
Run It Per Acceptance Channel
The SAQ decision flow
Once the gate question clears, walk each channel top to bottom: the first condition that matches sets the SAQ.
E-commerce
Payment page fully hosted by a compliant provider (full redirect or iframe)? → SAQ A
Merchant site delivers the payment form or its scripts (direct post / JavaScript)? → SAQ A-EP
API integration or anything else? → SAQ D
Mail / telephone order
All card handling fully outsourced to compliant providers? → SAQ A
Keyed into a browser-based virtual terminal on an isolated workstation? → SAQ C-VT
Standalone dial-out terminal → SAQ B · PTS terminal over IP → SAQ B-IP · P2PE-listed solution → SAQ P2PE
Internet-connected payment application → SAQ C · none of the above → SAQ D
Card-present (in store)
PCI-listed P2PE solution? → SAQ P2PE
Standalone dial-out terminals? → SAQ B
Standalone PTS-approved terminals over IP? → SAQ B-IP
Internet-connected POS application → SAQ C · virtual terminal → SAQ C-VT · otherwise → SAQ D
Gotchas that silently change the answer. Call recordings: phone payments captured on recorded lines mean stored account data, pause recording or use DTMF masking, or the channel falls to SAQ D. Flat networks: a virtual terminal or IP terminal sharing the LAN with everything else can break C-VT/B-IP eligibility, segmentation isn't optional there. VoIP: if voice and payment traffic share a network, scoping needs careful analysis before promising a light SAQ. Every criterion counts: miss one eligibility condition and the form is invalid, verify with the acquirer or a QSA when it's close.
03
The Annual Cycle
Validate & maintain: turn compliance into a deliverable
Merchant level (transaction volume, set per card brand) determines how the client validates; the SAQ determines what they answer; the AOC is what the acquirer actually collects, every year, with quarterly scans in between. PCI DSS isn't an annual event; the SAQ just attests that these activities ran all year.
Merchant Levels
Indicative thresholds: confirm per card brand & acquirer
| Level | Annual volume | How the client validates |
|---|---|---|
| L1 | 6M+ transactions/yr | Annual ROC by a QSA (or qualified ISA) + AOC + quarterly ASV scans. |
| L2 | 1–6M transactions/yr | Annual SAQ + AOC + quarterly ASV scans (some brands require ISA/QSA involvement). |
| L3 | 20k–1M e-com txns/yr | Annual SAQ + AOC + quarterly ASV scans. |
| L4 | Everyone else, most SMBs | Annual SAQ + AOC; scans as applicable. A breach can force L1 treatment. |
The Validation Artifacts
SAQ
The self-assessment itself, answered honestly, with evidence behind every "yes," signed by an officer of the client.
AOC
Attestation of Compliance: the summary the acquirer, partners, and customers actually request. One per SAQ or ROC.
ROC
Report on Compliance, full onsite assessment by a QSA, for Level 1 merchants and high-volume service providers.
ASV scans
Quarterly external vulnerability scans by an Approved Scanning Vendor with passing results, required for internet-facing CDEs (A-EP, B-IP, C, D, and others where externally exposed). Failed scan → remediate → rescan.
The Compliance Calendar
PCI DSS as business-as-usual
Build this cadence into your managed service and the renewal takes days, not months.
| Cadence | Recurring activities | Evidence produced |
|---|---|---|
| Daily / continuous | Automated log review and alerting; anti-malware active everywhere; backup jobs verified. | SIEM alerts & triage notes, EDR status reports |
| Monthly | Critical patches applied within 30 days; review of new systems entering scope. | Patch compliance reports, change tickets |
| Quarterly | ASV external scans + internal vulnerability scans with remediation-and-rescan; POS terminal inspections; PAN discovery sweeps; service-provider scope confirmation (for your MSP). | Passing ASV certificates, scan reports, inspection logs |
| Semi-annual | Firewall/NSC ruleset reviews; user access reviews across CDE systems. | Ruleset review sign-offs, access review exports |
| Annual | Risk assessments; penetration test with segmentation validation; security awareness training; incident-response plan test; policy review; vendor/AOC collection; SAQ + AOC renewal. | Pen test report, training records, IR tabletop minutes, signed SAQ & AOC |
Who Does What
Validation responsibility split
Typical allocation across the validation cycle for an MSP-supported merchant: the client signs, the MSP substantiates.
Scoping, data-flow diagrams & SAQ selection
MSP
Shared
Client
Running scans, pen tests & remediation
MSP
Shared
Client
Preparing SAQ answers & evidence
MSP
Shared
Client
Signing the SAQ/AOC & submitting to the acquirer
Shared
Client
Responding to acquirer/brand inquiries
MSP
Shared
Client
MSP leadsSharedClient leadsProportions measured from the source guide's chart: the responsibility matrix records the real allocation per client.
If card data is breached
Contain, preserve forensic evidence, and notify the acquirer and card brands immediately per their procedures, they direct next steps, which may include a PFI investigation. State breach-notification laws will usually apply on top. Your incident-response plan (Req 12.10) should already name these contacts.
Honesty clause
A check-the-box SAQ that doesn't match reality is worse than non-compliance, post-breach, the signed attestation becomes evidence against the client. Never let a client sign answers your evidence can't back. That's exactly the problem the next section solves.
ControlMap by ScalePad
From SAQ scramble to a running PCI program: in one platform
ControlMap is ScalePad's multi-tenant GRC platform built for MSPs. Everything this guide demands, scoping evidence, mapped PCI DSS controls, policies, training attestations, vendor AOCs, scan results, and the answers behind every SAQ "yes", lives in one workspace per client, so the annual attestation becomes an export, not a project.
The Five-Step ControlMap Workflow for PCI DSS
- 1
Onboard & adopt the framework
Create a dedicated client workspace and select PCI DSS from the framework library. Record the scoping artifacts, system inventory, network topology, card-data-flow diagrams per channel, as foundation documents. Cross-mapping means the same controls also feed CIS, NIST CSF, or SOC 2 later.
- 2
Run the gap & risk assessments
Baseline the client with built-in questionnaires, scoped to the SAQ type from the decision flow, and build the risk register: assets, threats, likelihood × impact, treatment decisions. The output doubles as the annual risk analysis Requirement 12 expects, exportable for the client's records.
- 3
Implement controls with in-tool guidance
Each control card explains the requirement, what "implemented" looks like, and what evidence satisfies it. Assign owners: your engineers for firewalls, MFA, and logging; client staff for terminal inspections and till procedures, and track gap → in progress → implemented on the dashboard.
- 4
Build policies from templates: signed
Start from the policy template library, information security, access control, acceptable use, incident response, vendor management, tailor to the merchant, version-control approvals, and push to staff for electronic acknowledgment, covering Requirement 12's policy and training paper trail automatically.
- 5
Collect evidence, renew the SAQ from it
Attach evidence to every control, ASV scan certificates, firewall review sign-offs, access-review exports, terminal inspection logs, automating what integrations allow. Recurring tasks re-prompt on the quarterly, semi-annual, and annual calendar, so at renewal the SAQ answers are already substantiated.
Package it as a service
Multi-tenant design means one pane for every merchant client. Productize it: Scope & Assess (data flows, SAQ selection, gap + risk) → Remediate (project work) → Manage (monthly compliance-as-a-service with the recurring calendar and annual SAQ renewal).
Make the QBR land
Show the owner the dashboard: posture score, closed gaps, this quarter's passing scan, next renewal date. "Your ability to take payments is protected, and here's the proof" is the strongest renewal argument in SMB IT.
Keep it alive
Scope drifts: a new payment channel, a developer's checkout tweak, a saved card list in a spreadsheet. Make "anything change about how you take payments?" a standing QBR question, and re-run the SAQ decision flow whenever the answer is yes.
Take Action
Map the platform, run the first 90 days, work the checklist
Where each part of the PCI program lives in ControlMap and the evidence acquirers expect; a realistic first-90-days arc per client; and the ten-point quick-start checklist to put the whole guide in motion.
ControlMap in Action
Mapping ControlMap to the PCI program
| Area | Do this in ControlMap | Evidence you'll bank |
|---|---|---|
| The 12 requirements | Adopt the PCI DSS framework; assign every requirement as a control with an owner; schedule the recurring cadence, quarterly scans and inspections, semi-annual firewall and access reviews, annual pen test and training. | Control status history · review sign-offs · patch & scan reports · training completion records |
| Scope & SAQ | Store the scoping pack (inventory, topology, card-data flows per channel); record the SAQ-type decision and its eligibility rationale; track segmentation checks and PAN-discovery sweeps as recurring controls. | Data-flow diagrams · documented SAQ eligibility decision · segmentation test results · clean PAN-discovery reports |
| Validation cycle | Attach passing ASV certificates each quarter; collect vendor AOCs in the vendor register (Req 12.8); run the annual SAQ refresh from last year's workspace; export the evidence bundle behind every answer. | Quarterly ASV certificates · vendor AOC library · signed SAQ & AOC archive · year-over-year posture reports |
| Your own MSP | Stand up a workspace for your own firm, as a service provider you'll face SAQ D-SP (or a ROC at scale), plus 12.9 responsibility acknowledgments and quarterly scope confirmations. Reuse the same framework internally. | Your SP-side SAQ D evidence · responsibility matrices for clients · proof for due-diligence questionnaires and cyber insurance |
Per Client
A realistic first-90-days arc
- W1-2
Contract & scope
Responsibility matrix in the MSA · workspace created · scoping pack: inventory, topology, card data flows.
- W3-6
Select & assess
SAQ type selected per channel · gap assessment & risk register complete · remediation plan priced and approved.
- W7-10
Remediate & pass
Segmentation & MFA in place · first ASV scan passing · policies approved · staff attestation launched.
- W11-13
Evidence & deliver
Evidence flowing · recurring calendar scheduled · SAQ + AOC completed and delivered at QBR.
Take Action
Your 10-point PCI DSS quick-start checklist
Contract the responsibility split
Put a PCI responsibility matrix in your MSA and acknowledge your service-provider duties in writing (12.8/12.9).
Map every payment channel
Chart the card data flow for e-commerce, MOTO, and in-store acceptance, before touching a questionnaire.
Hunt down stored card data
PAN discovery scans on file shares, email, and recordings; then eliminate or tokenize what you find.
Pull the scope-reduction levers
Hosted payment pages, P2PE terminals, tokenization, and network segmentation: the cheapest controls in the standard.
Run the SAQ decision flow
Per acceptance channel, and document the eligibility rationale in ControlMap.
Deploy the technical core
Enforce MFA into the CDE, unique IDs, default-deny firewalls, hardening baselines, and EDR everywhere.
Stand up the scan program
Quarterly ASV + internal scans with a remediate-and-rescan workflow, and an annual pen test.
Publish policies and train staff
Publish the policy set from ControlMap templates, run annual training, and collect staff e-attestations.
Rehearse incident response
Run the incident-response plan, with the acquirer and card-brand contacts already written into it.
Schedule the compliance calendar
In ControlMap, so the annual SAQ + AOC renewal becomes an export, not a project.
This guide is provided for general educational purposes and reflects PCI DSS v4.x as commonly understood at time of publication. It is not legal or QSA advice; SAQ eligibility, merchant levels, and validation requirements vary by card brand, acquirer, and environment, confirm specifics with the acquiring bank or a Qualified Security Assessor, and consult the official PCI SSC document library for current SAQs and criteria.
ControlMap by ScalePad
Turn PCI DSS into your next managed service
See how MSPs run multi-client PCI programs, scoping packs, SAQ selection, mapped controls, policies, and the evidence behind every attestation, in ControlMap.