PCI DSS Requirement 12.3.9 mandates that you allow the “Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use”. What does this mean in practice?
PCI DSS Service Providers – A Definition
In the early days of PCI DSS, I recall having many conversations with vendors of payment applications and card-related services in which we spent hours persuading and educating providers about their new obligations. This was before the Payment Application Data Security Standard (PA DSS), which gave us something more concrete to point to in these situations.
Thankfully, these conversations now are a rarity. However, as the banks extend their compliance focus to level three and four merchants, who may rely on locally grown applications and services, situations still may arise where a vendor does not know about PCI or PA DSS. Or the vendor simply may not consider their service subject to the standards.
For that matter, you may wonder if you are a service provider yourself! Many organizations make use of multiple merchant accounts for a variety of legitimate business reasons. In such circumstances, organizations may wrestle with this question.*
So, how does service provider compliance relate to merchant compliance? And how is service provider status determined?
Is a corporate service organization a Service Provider under PCI even if it is internal?
A reader recently submitted the following question to Ask PCI DSS Guru:
“A corporate service organization stores, processes, or transmits cardholder data on behalf of different departments. Each department is a merchant and there are thirty merchants . Is the corporate service organization a Service Provider under PCI even [if] it is internal?”
We saw this question arise about three years ago for a large institution (having just over 40 merchant accounts and over a dozen payment systems). We maintained (and the institution’s acquiring bank agreed) that because the merchant accounts belonged to a single entity the services provided by that entity to its internal constituents did not make that organization a service provider.
Obviously, all of those merchant accounts were still in scope for PCI DSS and each system had to be certified compliant. Here is another post that elaborates on the definition of a service provider under PCI.
Verifying Your PCI DSS Scope with Scanning Tools
With the release of PCI DSS 2.0 comes a new requirement – verifying that you’ve correctly identified the scope of your cardholder data environment. The PCI DSS compliance community believes, as a general principle, that you should limit the scope of your cardholder data environment to the greatest extent possible. This not only reduces the amount of work you will need to do to comply with the PCI DSS standard, but also reduces the overall risk to your organization by limiting complexity.
Verifying Scope
When a Qualified Security Assessor (QSA) prepares a Report on Compliance (RoC) for your company, they first must identify the scope of their assessment. They’re required to document that they’ve verified your approach in four ways. PCI DSS 2.0 states that they must verify: (continue reading…)
When Will I Be Asked To Comply With PCI DSS?
A reader recently submitted the following question to Ask PCI DSS Guru:
“When will merchants be contacted with the questionnaire for compliance? I have had card processing for 8 years and have never been contacted previously.”
