Some of the PCI standards apply to products and solutions that are
bought and used by participants in the payment system.
For example,
the secure software standard for payment applications, PTS
POI for card reading terminals, and P2PE, SPoC, and CPoC for
end‑to‑end payment solutions.
Once a product or solution has been assessed by the appropriate assessor,
the vendor of the product can apply to the PCI SSC for it to be listed on
the PCI SSC website as a validated product or solution.
Many card brands or schemes require their merchants and
financial institutions to only use products and solutions
that are listed by the PCI SSC.
There is a standard process when a vendor would like to get their
products or software validated by the PCI SSC.
Firstly, an approved assessor evaluates the product or
solution against the published standard.
The assessor produces a report in a form approved by the PCI SSC
and sends this report to the PCI SSC for review.
Once it's been reviewed,
validated products and solutions are then listed on the PCI SSC website.
So, let's look at a few examples to see how this works in practice.
Imagine an organization that would like to have their card reading point of
interaction device validated against the PCI PTS POI standard.
They send it to a PTS lab that evaluates the device
and produces an evaluation report,
which is then sent to the PCI SSC for evaluation and listing. What about a
software development company that wants their payment software to be
evaluated against the secure software standard?
They'd need to find a Secure Software Assessor who would,
after evaluating the software, produce a report on validation, or RoV,
which the software development company would then send to the PCI
SSC, who would review it, and then list the software on their list of
approved or validated payment software.
Finally,
how about a solution provider that had a point‑to‑point
encryption solution that they wanted validated?
The solution provider would employ a P2PE QSA to evaluate the
solution and produce a P‑RoV, a P2PE report on validation, and that
will be sent to the PCI SSC, who would review it, and then list the
P2PE solution on their website.
So that's how the programs work in respect to the hardware and software and
solutions where the PCI SSC receives the final report, so they can list the
product or solution on the PCI SSC website. Now let's have a look at how
organizations demonstrate their compliance with the PCI standards to each
other, actually. Standards that apply to how organizations look after payment
card data include PCI DSS, the data security standard, PCI PIN, the 3DS core
security standard,
token service provider standard, and the card production standard.
In this example,
one organization, I've called it Organization B, requires another organization,
say, Organization A, to comply with a PCI standard.
Typically, Organization B is an acquirer and Organization A is a merchant,
but it could be that Organization B is the merchant, asking their
third‑party service provider, Organization A, to be compliant.
So, Organization A will need to find an assessor authorized by
the PCI SSC to assess against the standard, and who will produce
the specified validation document, which Organization A can then
give to Organization B.
Let's work through some examples of this.
Let's start with the most simple example, an acquirer that
requires their merchant to comply with PCI DSS. The merchant
engages a Qualified Security Assessor,
a QSA, who produces a Report on Compliance, or RoC,
which is given to the merchant.
The merchant can then provide this Report on Compliance
to their acquirer. And very similarly, in a three‑party scheme,
the card scheme requires the merchant to demonstrate its compliance with PCI
DSS. The merchant hires a QSA, the QSA produces the Report on Compliance,
which the QSA gives to the merchant, then the merchant can pass on to the
card scheme that asked them to be compliant. As you'll discover, if you look
at PCI DSS in more depth,
it's always the responsibility of merchants to make sure
their third‑party service providers,
hosting companies, anyone who provides services that can
affect the security of cardholder data, those service
providers also have to comply with PCI DSS.
So if a merchant requires a third‑party service provider to validate its
compliance with PCI DSS, the third party will hire a Qualified Security
Assessor, who will produce the Report on Compliance and give that to a service
provider. Then the service provider will be able to produce this Report on
Compliance and give it to the merchant to prove that they are compliant with
PCI DSS. We'll look at just a few more examples quite quickly. A card scheme
that requires an acquiring bank to comply with the PCI PIN requirements, in
this case,
the assessor that's required is a Qualified PIN Assessor, or QPA. The
documentation, the assessment, is provided by the assessor to the acquirer, and
then the acquirer can pass it to the card scheme. And it's pretty similar for a
card scheme that wants to make sure a card production facility complies with
the PCI card production standards.
A Card Production Security Assessor will undertake the assessment,
produce two Reports on Compliance,
one for logical one for physical security, and then give them to
the vendor, who can pass them to the card scheme.
Finally,
an acquiring bank might ask a merchant to commission a PFI,
a PCI forensic investigator, to investigate the cause of a
breach of cardholder data.
The PFI will produce the PFI Forensic Report for the merchant to
give to their acquirer. So, as we've seen,
each of the PCI standards has an approved assessor and specified
documents to report the results of an assessment.