Gateways, PSPs and processors
PCI DSS has a set of requirements that exists only for service providers, and an entire appendix for those hosting multiple customers in a shared environment. DM11 prepares your company for the right route, without discovering the real scope mid-assessment.
DM11 prepares your company. We are not a QSA and we do not issue RoC, AOC or certificates. Where a formal assessment is required, it is conducted by a partner QSA qualified by the PCI SSC.
Who runs the preparation
The question that decides everything
The answer changes the set of requirements, how you validate and how often each routine runs. The standard defines a service provider as an entity that processes, stores or transmits card data on behalf of another entity, or that can impact the security of that data. Gateways, sub-acquirers, facilitators and processors sit there. And a company that sells directly and also processes for others carries both roles.
The standard covers this case: where the entity assessed is both merchant and service provider, the service-provider-only requirements apply to the part of the business that provides the service. In practice these are two scope tracks inside one assessment, and treating them as one is an expensive mistake.
Whoever hires you has to monitor your compliance status at least every twelve months and know which requirements are yours, which are theirs and which are shared. That is not curiosity: it is their own requirement, and the answer you give determines whether the contract moves.
Appearing on a card brand's list of compliant service providers helps your customer meet their annual monitoring duty. But the standard is explicit: as evidence of requirements you meet on their behalf, the listing is not sufficient. You are expected to hand over the AOC on request.
What changes for a provider
PCI DSS marks a series of requirements as applying only to service providers, and doubles the frequency of routines a merchant performs once a year. Anyone building the programme with a merchant mindset finds this out late.
PCI DSS v4.0.1, published in June 2024. Version 4.0 was retired in December 2024, making it the only active version. The Report on Compliance template is at revision 3, from January 2025.
Most of the new requirements in version 4 were best practice until 31 March 2025 and became mandatory on that date. Several of them hit service providers hardest, especially the semiannual scoping ones and those in the shared environment appendix.
SAQ D for Service Providers is the only self-assessment option for a provider, and only for those a card brand deems eligible. It carries the provider-only requirements in full plus the shared environment appendix, neither of which exists in the merchant SAQ.
A merchant confirms scope once a year. A provider confirms every six months and after any significant change. The standard's own reasoning is that provider networks are larger, more complex and change more often.
Where a merchant tests segmentation once a year, a provider tests every six months and after any change to segmentation controls. And whoever hosts multiple customers has a second test, additional to that one.
The standard offers providers two options: run an annual assessment and give customers the evidence, or be assessed on demand by each customer and take part in each of their assessments. The second trades one project a year for a queue of them.
Which route is yours
The route follows from how data flows, who you serve and the volume you handle on behalf of others. Thresholds and validation methods are set by the card brands and your acquirer, not by the PCI Security Standards Council.
| Your profile | Validation route | What it demands |
|---|---|---|
| Card data never touches your environment | SAQ A | The shortest set of controls. It does not apply to service providers: it is a merchant route. |
| Data passes through you, but you sell to your own end customers | SAQ D Merchant | The full standard from a merchant's perspective, without the provider-only requirements. |
| You process, store or transmit on behalf of other companies, within the brand's threshold | SAQ D Service Provider | The full standard, plus provider-only requirements, plus the shared environment appendix if you host multiple customers. It also requires describing test results per requirement, not just ticking yes or no. |
| Above the brand's threshold, or where your acquirer requires it | Report on Compliance | A formal assessment conducted by a QSA, in the official template, with independent scope validation by the assessor. It is also the route to appearing on the card brands' compliant provider lists. |
Visa publishes a threshold of 300,000 annual transactions separating Level 1 from Level 2 service providers, with a QSA Report on Compliance at Level 1 and self-assessment at Level 2. Quarterly external scanning by an approved vendor applies to both levels. Mastercard classifies by service category and annual volume under its own programme. Confirm your classification with your acquirer before choosing a route.
What applies only to you
The standard marks these as applying only to service providers. Anyone building a programme from generic PCI DSS material simply never finds them, and discovers the gap when the assessor asks.
A description of every algorithm, protocol and key protecting stored data, with strength and expiry, plus an inventory of cryptographic modules with type and location. And production keys cannot be reused in test environments.
If you share cryptographic keys with the customers you serve, you must document and distribute guidance on secure transmission, storage and updating of those keys.
If you access your customers' environments remotely, the authentication factor must be unique per customer. A credential used for one customer cannot work for another.
Where a password is the only access factor for your customer's users to card data, either it changes every ninety days, or you dynamically analyse the account's security posture and decide access in real time.
Every six months and after any change to segmentation controls, confirming the card environment is isolated from all out-of-scope systems. The tester needs organisational independence, and need not be a QSA.
Intrusion detection must identify, alert on and address covert communication channels used by malware, and the incident response plan must cover responding to that detection.
Formal executive accountability for the programme, with a charter communicated to senior management. Plus reviews every three months confirming tasks are being performed per policy, carried out by people other than those performing the task.
Scope confirmation every six months, and a documented impact review whenever there is a relevant change in company structure, such as a merger, acquisition or reassignment of control owners, with results communicated to senior management.
A written agreement acknowledging your responsibility for the security of data you hold on their behalf. And responding, on request, to enquiries about compliance status and about how responsibility is split per requirement.
Shared environment
The standard deals separately with those offering shared services to multiple customers, with system resources, infrastructure, applications or databases in common. The text names gateway and processing services in shared environments explicitly. Providers offering only shared data centre space, the colocation model, fall outside this appendix.
The provider cannot access a customer's environment without authorisation, and a customer cannot access the provider's environment without authorisation. Each customer reaches only their own card data and consumes only the resources allocated to them, without impacting others.
The effectiveness of separation between customer environments is confirmed by penetration testing every six months. The standard is explicit that this test is additional to the segmentation pentest, not a replacement. They are two distinct exercises in the same half-year.
Logging enabled by default for each customer's environment, available for review only by the customer who owns it, with the log location clearly communicated to them.
The ability to support prompt forensic investigation for an incident affecting any customer, and a secure channel for customers to report incidents and vulnerabilities, with handling and remediation.
Anyone running a shared environment must support their customers' external penetration testing. The standard says why, plainly: forbidding it would leave their systems open to exploitation.
Worth noting what the standard itself observes: even where the provider meets these requirements, each customer remains responsible for meeting and validating the requirements applicable to their own environment. Your compliance does not transfer compliance to those you serve, and promising that commercially creates a problem later.
What you hand your portfolio
Here is a competitive edge few exploit. How you deliver the payment page determines which self-assessment your merchant customers can use, and the gap between the shortest and the next one is large. This is a selling argument for your portfolio, and it is verifiable in PCI Security Standards Council material.
| How you integrate | Your customer's self-assessment | Condition |
|---|---|---|
| Full outsourcing, such as a payment link sent to the cardholder | SAQ A | The script protection criterion does not apply to this model. |
| Redirect from the customer's site to your environment | SAQ A | The script criterion does not apply to redirects either, provided the other criteria are met. |
| Embedded page or form, typically via iframe | SAQ A | Only if the customer protects the page themselves, or if you provide written confirmation that your solution, implemented per your instructions, protects the page against script attacks. |
| The customer's site controls the flow and affects the page's integrity | SAQ A-EP | Considerably broader. If you host the site and run a shared environment, meeting the multi-tenant appendix is a prerequisite for your customer's eligibility. |
| Card data reaches the customer's own site | SAQ D Merchant | The customer's environment comes into scope entirely. |
The third row is the opportunity. A provider that implements script management and change detection in its own iframe solution, and issues the written confirmation, keeps its portfolio on the shortest self-assessment instead of pushing it to the next one. Those who do not, push. The final decision on which self-assessment applies always rests with the customer's acquirer or card brand.
Who does what
In a market where certificates get promised by people who cannot issue them, we would rather be clear from the start about who signs what. It changes what you should demand from us and what you need to solve elsewhere.
Self-assessment
The first questions classify your case and point to a validation route. The rest walk through the chapters of the standard and show where the gaps are. The full result appears on screen, with the route, a score per chapter and what closes each gap. We do not ask for your email to show it.
How we run it
Every phase ends with a deliverable. You know what you get before you start.
We map the data flow, the connected systems and those that can impact the environment's security. We separate the merchant track from the provider track where a company carries both roles, because treating them as one distorts everything downstream.
You get
Before implementing controls, we remove what does not need to be in scope. Segmentation, eliminating unnecessary storage and revisiting integrations shrink the whole programme at once.
You get
We work with your team on what is missing in each chapter, with particular attention to the provider-only requirements and the shared environment appendix, which are usually absent.
You get
Provider compliance is a calendar, not a project. We structure the quarterly reviews, the semiannual scope confirmation, the pentests at the correct frequency and the quarterly scanning.
You get
We build what your customers' due diligence will ask for: a responsibility matrix per requirement, the written responsibility agreement and the process for answering status requests.
You get
We organise the evidence in the format the assessor expects and run a dry run before the real assessment. Where the route is a Report on Compliance, we coordinate with the partner QSA, preserving the separation of roles.
You get
Stories
We anonymise our clients with the same confidentiality that will protect your company later. The names change, and the pattern of the problems repeats.
Frequently asked
Answers anchored in the PCI Security Standards Council's standard and the card brand programmes. Where no official figure exists, we say so.
No. DM11 is not a QSA and does not issue a Report on Compliance, attestation or certificate. We prepare: we design and reduce the scope, implement the controls, build the recurring routines, run the segmentation pentest and organise the evidence. Where your route requires a formal assessment, it is conducted by a qualified partner QSA, with roles separated between whoever prepared and whoever assesses.
More questions? Talk to DM11
A thirty minute conversation is usually enough to separate what is a provider obligation, what is a merchant one, and which validation route applies to your case. No obligation.