If your MSP manages anything that can affect the security of a client’s cardholder data environment (CDE), PCI DSS treats you as a service provider. Examples include the firewall in front of a point-of-sale (POS) network, remote access to payment terminals, the servers behind an e-commerce checkout, and endpoint management on machines that take card payments. Clients who take cards then have to collect evidence that you are compliant, and you have to be able to provide it.
In practice, that means validating your own PCI DSS compliance, either with SAQ D for Service Providers or with a Report on Compliance. It also means giving clients an Attestation of Compliance (AOC) that covers the services you deliver to them, plus a clear record of which requirements you own, which they own and which you share. So when a client asks whether you’re required to provide an AOC, the answer is often yes. This guide explains when that applies and how to turn it into a recurring service without suggesting you certify anyone. It is general information, not QSA or legal advice.
When is an MSP a PCI DSS service provider?
The PCI SSC glossary defines a service provider as a business entity, other than a payment brand, that is directly involved in processing, storing or transmitting cardholder data on behalf of another entity. The definition goes on to include companies whose services “control or could impact the security” of cardholder data, and it names managed service providers offering managed firewalls and IDS as examples, along with hosting providers.
That second clause is the one that catches most MSPs. You don’t need to handle card numbers to be in scope. Some typical cases:
| MSP service | Likely a PCI service provider? | Why |
|---|---|---|
| Manages the firewall or router segmenting a POS network | Yes | Controls the boundary of the CDE |
| Remote access or RMM on POS terminals or payment workstations | Yes | Can change systems that handle card data |
| Hosts or administers an e-commerce site that loads a payment form | Usually yes | Can change scripts on the payment page |
| Manages Microsoft 365 for an office fully segmented from payments | Often no | No path to the CDE, if segmentation is real and verified |
| Resells a processor’s terminal with no admin access | Often no | No control over CDE security |
Whether a service is in scope is a scoping decision for the client and its assessor, not a label the MSP picks for itself. If you can reach the CDE, assume you’re in scope until segmentation testing and documentation say otherwise.
What does being a service provider require?
Validate your own compliance with the right form
PCI SSC FAQ 1578 (June 2024) is direct about this: “The only correct SAQ for a service provider is SAQ D for Service Providers.” Merchant SAQs such as SAQ A or SAQ C-VT assume the merchant has outsourced its account data handling. A service provider that relies on one would skip controls it actually needs. The FAQ also says that a merchant SAQ or merchant AOC handed to customers is not sufficient evidence of a service provider’s compliance.
Larger service providers may be required by the payment brands to undergo a full ROC by a QSA instead of self-assessing. Each brand sets its own thresholds, so check their service provider programs.
Give clients evidence they can use
PCI SSC FAQ 1576 (February 2024) sets out what a third-party service provider (TPSP) should provide:
- If you have your own assessment: provide your AOC on request, covering the services the client actually uses. Clients may also ask for relevant sections of your ROC or SAQ D for Service Providers.
- If you don’t: provide specific evidence for each applicable requirement, so the client or its assessor can confirm the requirement is met. In practice, that usually means taking part in each client’s assessment, which gets expensive once you serve more than a handful of card-taking clients.
For most MSPs with several payment clients, one annual SAQ D for Service Providers and an AOC is cheaper than repeating the evidence work for every client.
What do requirements 12.8 and 12.9 ask of each side?
PCI DSS v4.0.1 splits third-party obligations between the client (12.8) and the service provider (12.9). The full text is in the PCI SSC document library.
| Requirement | Who it applies to | What it asks for |
|---|---|---|
| 12.8.1 | Client | Maintain a list of TPSPs that handle or could affect account data, with a description of the services each provides |
| 12.8.2 | Client | Written agreements with those TPSPs that include their acknowledgment of security responsibility |
| 12.8.3 | Client | A process for due diligence before engaging a TPSP |
| 12.8.4 | Client | Monitor each TPSP’s PCI DSS compliance status at least once every 12 months |
| 12.8.5 | Client | Maintain information on which requirements each TPSP manages, which the client manages and which are shared |
| 12.9.1 | MSP (service provider) | Acknowledge in written agreements your responsibility for the security of account data you handle or could affect |
| 12.9.2 | MSP (service provider) | Support client requests for your compliance status and for information on which requirements are yours, theirs or shared |
The v4.0.1 notes for 12.9.1 say that an AOC, a website statement, a policy or a responsibility matrix does not count as the written acknowledgment. The acknowledgment has to be in the agreement itself. Update your master services agreement or PCI addendum, and don’t count on the matrix alone.
How should an MSP build a responsibility matrix?
The matrix is the document that answers 12.8.5 for your client and 12.9.2 for you. PCI SSC’s Information Supplement: Third-Party Security Assurance (March 2016, written against an earlier PCI DSS version) includes a sample matrix in Appendix B. FAQ 1576 points to it as a model.
A practical structure lists each applicable requirement, the owner and the evidence:
| Requirement area | MSP | Client | Shared | Evidence the owner keeps |
|---|---|---|---|---|
| 1: Network security controls (managed firewall) | ✓ | Firewall rule reviews, change tickets | ||
| 2: Secure configurations (managed endpoints) | ✓ | MSP hardening baseline; client approval of exceptions | ||
| 5: Anti-malware on payment workstations | ✓ | EDR console reports | ||
| 6.4.3: Payment page scripts (if MSP hosts the site) | ✓ | Script inventory; client sign-off on business justification | ||
| 8: User accounts and MFA for MSP technicians | ✓ | Access reviews, MFA enforcement logs | ||
| 8: User accounts for client staff | ✓ | Client’s joiner/leaver records | ||
| 9: Physical security of terminals | ✓ | Device inventory and inspection logs | ||
| 10: Logging on managed systems | ✓ | Log retention and review records | ||
| 12: Security policy and incident response | ✓ | Client policies; MSP incident escalation runbook |
Keep the matrix specific to each client’s services. A generic “we handle security” row will not satisfy an assessor. Review it whenever the scope changes, and at least annually, which lines up with the client’s 12.8.4 monitoring. You can start from the MSP PCI responsibility matrix template.
How can MSPs package PCI help for small merchants?
Most small merchants validate with a short SAQ, pay a monthly PCI non-compliance fee when they miss a deadline, and don’t know which PCI SAQ they need. That makes PCI a good fit for a recurring MSP service, as long as the scope and wording are right.
What to include
- Scoping and SAQ selection: map how the client takes cards, then recommend the SAQ type for the client and its acquirer to confirm.
- Scope reduction: move clients to hosted payment pages or terminals with point-to-point encryption where possible. Less scope is the cheapest control.
- Evidence upkeep: quarterly ASV scans where required, policy reviews, access reviews and (for e-commerce clients) payment page script requirements.
- Annual SAQ support: help the client answer and assemble the SAQ. The client’s own officer signs the AOC.
- Your own AOC and matrix: provide both every year, as part of the service rather than as an extra.
- Fraud monitoring: card-testing attacks hit small merchants hard. See what to do in a card-testing attack.
What not to say
Only the PCI SSC can qualify assessors, and only QSAs (or an ISA inside the entity) perform formal assessments. Unless you are a QSA company, avoid “we certify,” “PCI certified clients” or “guaranteed compliant.” Say “we help you complete and maintain your PCI validation” and “we provide evidence for the controls we manage.” Put that wording in your contracts too, next to the 12.9.1 acknowledgment.
How does CardSecurity help MSPs?
CardSecurity is sold through MSPs. Today, in pilot, the MSP partner portal lets you manage many merchants from one place, with admin, standard and viewer roles scoped per organization. It also includes card-testing protection, and card entry runs in Payroc Hosted Fields, so CardSecurity never sees card numbers. CardSecurity is building PCI compliance management for SAQs, evidence, policies and signed evidence packs. It is in development and not yet available. CardSecurity never certifies compliance. It helps you and your clients keep the evidence an assessor or acquirer asks for.
Frequently asked questions
Does every MSP need to provide an AOC to clients?
No. Only MSPs whose services store, process or transmit cardholder data, or could affect its security, are service providers for those clients. For them, an AOC covering the relevant services is the usual evidence (FAQ 1576). An MSP that doesn’t have one must instead provide requirement-by-requirement evidence for each client’s assessment. MSPs with no path to the CDE generally don’t need one.
Can an MSP use SAQ A or another merchant SAQ for itself?
No. PCI SSC FAQ 1578 states that the only correct SAQ for a service provider is SAQ D for Service Providers. Merchant SAQs assume card data handling is outsourced, so they leave out controls a provider needs. A merchant SAQ or merchant AOC from a service provider is not sufficient evidence for its customers.
Is a responsibility matrix enough to meet 12.9.1?
No. The v4.0.1 notes for 12.9.1 say a responsibility matrix, an AOC, a policy or a website statement is not the written acknowledgment. The acknowledgment must be in your written agreement with the client. The matrix still matters, because it supports your client’s 12.8.5 records and your 12.9.2 duty to explain who owns which requirements.
Can an MSP sign a client’s SAQ or certify them as PCI compliant?
No. The merchant attests to its own compliance, and an officer of the merchant signs the AOC. An MSP can help prepare the SAQ and the evidence for the controls it manages. Only a QSA, or an ISA within the entity, performs formal assessments, so avoid “certified” language in marketing and contracts.
How often should an MSP update its AOC and matrix?
At least annually, because clients must check each provider’s compliance status at least once every 12 months under 12.8.4. Update the matrix sooner when services change: for example, when you take over a client’s firewall, begin hosting their website or add remote access to payment systems. Reissue the AOC whenever your assessment is renewed.
To see how CardSecurity fits into your managed services stack, start with the CardSecurity MSP program and the PCI MSP responsibility matrix.