The necessary ones make the site work. The others measure which pages help and which ads bring the people who need DM11. Your choice, and you can revisit it from the footer.
Gateways, payment providers (PSP) and processors
PCI DSS, the payment card security standard, has a set of requirements that exists only for companies serving other companies, plus an entire appendix for those hosting multiple customers in one shared environment. DM11 guides your company down the right route, without the nasty surprise of finding the real size of the job mid-assessment.
DM11 prepares your company. We are not a QSA, the qualified assessor, and we do not issue the Report on Compliance (RoC), the Attestation of Compliance (AOC) or certificates. Where a formal assessment is required, it is conducted by a partner QSA, qualified by the PCI SSC, the council that maintains the standard.
Who runs the preparation
The question that decides everything
The answer changes everything: which requirements apply, how you prove them and how often you repeat each routine. The standard calls a service provider anyone who processes, stores or transmits card data on behalf of another company, or who can affect the security of that data. Gateways, sub-acquirers, facilitators and processors all count. And a company that sells directly and also processes for others carries both roles at once.
The standard itself expects this: when a company is a merchant and a provider at once, the requirements that apply only to providers cover the part of the business that provides the service. In practice, these are two scopes inside one assessment. Treating them as one is a mistake that costs dearly.
Whoever hires you has to check on your compliance at least once every twelve months and know which requirements are yours, which are theirs and which you share. It is not curiosity: it is their own duty. And the answer you give decides whether the contract moves or stalls.
Appearing on a card brand's list of compliant providers helps your customer meet their annual check. But the standard is clear: to prove the requirements you meet on their behalf, the list alone is not enough. You are expected to hand over the AOC when asked.
What changes for a provider
PCI DSS marks a series of requirements as applying only to service providers, and it doubles the frequency of routines a merchant does once a year. Anyone building the program with a merchant mindset only realizes this far too late.
The version in force is PCI DSS v4.0.1, published in June 2024. Version 4.0 was retired in December 2024, so this is 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 only a recommendation until 31 March 2025 and became mandatory on that date. Several of them hit providers harder, especially the ones about six-month scoping and the ones in the shared environment appendix.
SAQ D for Service Providers is the only self-assessment questionnaire (SAQ) for a provider, and it is only for those a card brand deems eligible. It carries all the provider-only requirements and the shared environment appendix, which do not appear in the merchant SAQ.
A merchant confirms scope once a year. A provider confirms every six months, and also after any significant change. The standard itself explains why: a provider's network tends to be larger, more complex and to 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 on top of that one.
The standard gives a provider two options: run one assessment a year and give customers the proof, 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
Your route depends on how the data flows, who you serve and the volume you handle on behalf of others. Thresholds and how you validate 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 point of view, 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 the provider-only requirements, plus the shared environment appendix if you host multiple customers. Here you have to describe the result of each test, requirement by requirement, not just tick 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 the assessor confirming the scope on their own. It is also the way onto the card brands' compliant provider lists. |
Visa publishes a threshold of 300,000 transactions a year to separate a Level 1 provider from a Level 2: Level 1 goes to a QSA Report on Compliance, and Level 2 to self-assessment. The quarterly external scan, run by an approved vendor, applies at both levels. Mastercard uses a different measure, by service category and annual volume, under its own program. Confirm your classification with your acquirer before choosing a route.
What applies only to you
The standard marks these requirements as applying only to service providers. Anyone building a program from generic PCI DSS material simply never sees them, and finds the gap when the assessor asks.
A description of every algorithm, protocol and key that protects stored data, with strength and expiry date, plus an inventory of the cryptographic modules, with type and location. And a key used in production cannot be reused in the test environment.
If you share cryptographic keys with the customers you serve, you have to document and pass on guidance on how to transmit, store and update those keys securely.
If you access your customers' environments remotely, the authentication factor has to be unique for each customer. A credential used for one customer cannot work for another.
When a password is the only way your customer's user reaches card data, you have two options: either it changes every ninety days, or you check the account's situation in real time and decide access on the spot.
Every six months, and after any change to segmentation controls, to confirm the card environment is isolated from every out-of-scope system. Whoever runs it needs independence inside the company, but does not have to be a QSA.
Intrusion detection has to find, alert on and deal with the hidden communication channels that malware uses. And the incident response plan has to cover what to do when that is detected.
Senior management formally takes on responsibility for the program, with a charter that puts this on record and shares it with them. And every three months someone confirms the tasks are being done according to policy, always a person other than the one doing the task.
Scope confirmation every six months, and a documented impact review whenever the company changes in a relevant way, such as a merger, acquisition or a change in who answers for the controls, with the result shared with senior management.
A written agreement acknowledging that you are responsible for the security of the data you hold on the customer's behalf. And answering, when asked, questions about your compliance status and about who answers for each requirement.
Shared environment
The standard deals separately with those offering a shared service to multiple customers, with systems, infrastructure, applications or databases in common. The text names gateway and processing services in shared environments by name. Whoever only offers a shared data center, the colocation model, falls outside this appendix.
The provider does not enter the customer's environment without authorisation, and the customer does not enter the provider's environment without authorisation. Each customer reaches only their own card data and uses only the resources set aside for them, without getting in others' way.
Every six months, a penetration test confirms that the separation between customer environments is working. The standard is clear: this test is on top of the segmentation pentest, and does not replace it. They are two different exercises in the same half-year.
Logging is on by default for each customer's environment, and only the customer who owns that environment can view it, with the log location clearly told to them.
The ability to support forensic investigation right away in an incident affecting any customer, and a secure channel for customers to report incidents and vulnerabilities, with handling and remediation.
Whoever runs a shared environment has to support the customers' external penetration testing. And the standard says why, plainly: forbidding it would leave their systems open to attack.
Worth noting what the standard itself observes: even where the provider meets these requirements, each customer stays responsible for meeting and validating the requirements of their own environment. Your compliance does not pass compliance on to those you serve, and promising that in a sale becomes a problem later.
What you hand your portfolio
Here is a competitive edge few people use. How you deliver the payment page decides which self-assessment your merchant customer can use, and the gap between the shortest and the next one is large. This is a selling point for your portfolio, and you can prove it 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 requirement to protect the page against scripts does not apply to this model. |
| Redirect from the customer's site to your environment | SAQ A | The script requirement does not apply to redirects either, as long as 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 give written confirmation that your solution, installed as you instruct, protects the page against script attacks. |
| The customer's site controls the flow and affects the page's integrity | SAQ A-EP | Considerably longer. If you host the site and run a shared environment, meeting the multi-tenant appendix is a prerequisite for your customer to be eligible. |
| Card data reaches the customer's own site | SAQ D Merchant | The customer's environment comes fully into scope. |
The third row is the opportunity. A provider that puts script management and change detection inside 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 call on which self-assessment applies always rests with the customer's acquirer or card brand.
Who does what
In a market where people promise certificates they cannot issue, 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 with others.
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 for each chapter and what closes each gap. And 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 the ones that affect the environment's security. We separate the merchant track from the provider track when a company carries both roles, because treating them as one distorts everything downstream.
You get
Before installing any control, we clear out what does not need to be in scope. Segmentation, ending unnecessary storage and reviewing integrations shrink the whole program at once.
You get
We work with your team on what is missing in each chapter, with special attention to the provider-only requirements and the shared environment appendix, which are usually left out.
You get
Provider compliance is a calendar, not a project. We set up the quarterly reviews, the six-month scope confirmation, the pentests at the right frequency and the quarterly scan.
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 organize the proof in the format the assessor expects and run a rehearsal before the real assessment. Where the route is a Report on Compliance, we line things up with the partner QSA, keeping the roles separate.
You get
Stories
We swap our clients' names with the same confidentiality that will protect your company later. The names change, and the pattern of the problems repeats.
Frequently asked
Answers grounded in the PCI Security Standards Council's standard and the card brand programs. 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, install the controls, build the recurring routines, run the segmentation pentest and organize the proof. Where your route requires a formal assessment, it is conducted by a qualified partner QSA, with the roles separated between whoever prepared and whoever assesses.
It depends on your level, which is set by the card brands and administered by your acquirer, not by the PCI SSC. Visa publishes a threshold of 300,000 transactions a year: above it, a Level 1 provider with a QSA Report on Compliance; below it, Level 2 with self-assessment. Mastercard uses service category and annual volume under its own program. The quarterly external scan by an approved vendor applies at both levels. Confirm your classification with your acquirer before deciding.
There is only one: SAQ D for Service Providers. And it is only for those a card brand deems eligible to self-assess. It carries all the provider-only requirements and the shared environment appendix, which do not exist in the merchant SAQ. Another difference that catches people coming from the merchant world: the current version asks you to describe the result of each requirement's test, not just tick whether it is met.
The standard covers exactly this situation: the requirements marked as provider-only apply to the part of the business that provides the service. In practice, these are two scope tracks inside the same assessment, and treating them as one distorts the sizing. It is one of the first things we separate at the start of a project, because everything that follows depends on it.
Beyond a set of requirements that simply does not exist for merchants, the frequency of important routines changes. Scope confirmation goes from annual to semiannual. Segmentation penetration testing goes from annual to semiannual, and also after any change to segmentation controls. Quarterly execution reviews come in, carried out by people who do not perform the task, along with formal executive accountability for the program. The standard itself explains why: a provider's network is larger, more complex and changes more often.
It adds an entire appendix, which the standard created for that case and in which it names gateway and processing services in shared environments by name. It requires separation in both directions between provider and customer, assurance that one customer cannot reach another's data or resources, per-customer logging visible only to the owner, a channel to report incidents and support for forensic investigation. And it requires a penetration test every six months of the separation between customers, which the standard expressly says is on top of the segmentation test. Two different exercises in the same half-year. Whoever offers only a shared data center, in the colocation model, falls outside this appendix.
No, and promising that in a sale becomes a problem later. The standard records that, even with the provider meeting the shared environment requirements, each customer stays responsible for meeting and validating the requirements of their own environment. What you do for a customer is reduce their effort, hand over proof and own your side of the responsibility matrix. That is a lot, and it sells, but it is not a transfer of compliance.
It does, a lot, and it is a commercial lever few people use. If you deliver by redirect or full outsourcing, the requirement to protect the page against scripts does not fall on the customer. If you deliver an embedded page via iframe, the customer only sustains the shortest self-assessment by protecting the page themselves or by receiving written confirmation from you that your solution, installed as you instruct, protects against script attacks. A provider that installs the script inventory and the change detection and issues that confirmation keeps its portfolio on the shorter route. Those who do not push the customer onto the next route, which is much longer.
It is, with one caveat. The standard recognizes that being on a brand's list can be enough proof for the customer to meet their annual status check, as long as it is clear that the services they hired were covered by the assessment. But to prove the requirements you meet on the customer's behalf, the list is not enough: you are expected to hand over the attestation when asked. At the two main brands, the way onto the list runs through a formal QSA assessment and a registration done by the acquirer or the institution sponsoring you.
You can, and the standard provides for that option, but it is worth understanding what it means in practice. The two official alternatives are: run one assessment a year and give customers the proof, or be assessed on demand by each customer and take part in each of their assessments, delivering the result to each. In the second, you trade one exercise a year for a queue of them, with different teams, different deadlines and different scopes. For anyone with a sizeable portfolio, it usually costs more in money and in technical team time.
It is the version 4 novelty that lets you meet a requirement's objective with a control different from the one the standard describes. The text is clear about who it is for: companies mature in risk management, willing to take on a documentation and validation effort greater than the traditional approach. It requires a controls matrix, a risk analysis per control and documented effectiveness testing, and it has to be documented by a QSA or a qualified internal assessor. Anyone doing a self-assessment cannot use it. It also does not combine with a compensating control. It usually makes sense in modern architecture, where the real control does not look like the wording of the standard.
Version 4.0.1, published in June 2024. Version 4.0 was retired in December 2024, so it is the only active version. The Report on Compliance template is at revision 3, from January 2025. Worth noting the date that catches a lot of people: most of the new requirements in version 4 were only a recommendation until 31 March 2025 and became mandatory on that date. A program documented before that and not revised probably has a gap.
It depends on two things that only become clear in the diagnosis: the real size of the scope and how much of it can be reduced right at the start. We do not publish a standard timeline because it would be guesswork, and because the PCI SSC does not release a typical project duration. What we can say for sure is that scope definition is what moves the schedule most, and that hiring an assessment before knowing the size of the environment usually costs a whole cycle.
The PCI SSC does not publish failure statistics, so we do not repeat a blog ranking. What the official material itself warns about is useful and easy to check: a requirement does not count as met just because it is planned for later; the answer cannot be copied from another requirement or from a previous cycle; and a requirement excluded without analysis has to be marked as not tested, which shows up on the attestation as a partial assessment. On scope, the published rule of thumb is to start by assuming everything is in scope until you prove otherwise, and the assessor confirms the scope on their own, noting where they disagreed with yours.
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.