WEBVTT 00:00:00.940 --> 00:00:04.570 Some of the PCI standards apply to products and solutions that are 00:00:04.570 --> 00:00:07.450 bought and used by participants in the payment system. 00:00:07.840 --> 00:00:08.610 For example, 00:00:08.700 --> 00:00:12.690 the secure software standard for payment applications, PTS 00:00:12.690 --> 00:00:18.940 POI for card reading terminals, and P2PE, SPoC, and CPoC for 00:00:18.940 --> 00:00:20.760 end‑to‑end payment solutions. 00:00:21.740 --> 00:00:25.140 Once a product or solution has been assessed by the appropriate assessor, 00:00:25.380 --> 00:00:30.260 the vendor of the product can apply to the PCI SSC for it to be listed on 00:00:30.260 --> 00:00:34.160 the PCI SSC website as a validated product or solution. 00:00:34.940 --> 00:00:38.290 Many card brands or schemes require their merchants and 00:00:38.290 --> 00:00:42.140 financial institutions to only use products and solutions 00:00:42.140 --> 00:00:44.260 that are listed by the PCI SSC. 00:00:45.440 --> 00:00:47.970 There is a standard process when a vendor would like to get their 00:00:47.970 --> 00:00:51.160 products or software validated by the PCI SSC. 00:00:52.240 --> 00:00:55.850 Firstly, an approved assessor evaluates the product or 00:00:55.850 --> 00:00:58.360 solution against the published standard. 00:00:58.940 --> 00:01:03.620 The assessor produces a report in a form approved by the PCI SSC 00:01:03.830 --> 00:01:07.460 and sends this report to the PCI SSC for review. 00:01:08.840 --> 00:01:10.170 Once it's been reviewed, 00:01:10.340 --> 00:01:15.370 validated products and solutions are then listed on the PCI SSC website. 00:01:15.380 --> 00:01:18.950 So, let's look at a few examples to see how this works in practice. 00:01:20.340 --> 00:01:24.440 Imagine an organization that would like to have their card reading point of 00:01:24.440 --> 00:01:30.450 interaction device validated against the PCI PTS POI standard. 00:01:31.140 --> 00:01:34.590 They send it to a PTS lab that evaluates the device 00:01:34.810 --> 00:01:36.930 and produces an evaluation report, 00:01:36.940 --> 00:01:42.580 which is then sent to the PCI SSC for evaluation and listing. What about a 00:01:42.580 --> 00:01:45.890 software development company that wants their payment software to be 00:01:45.890 --> 00:01:49.060 evaluated against the secure software standard? 00:01:49.740 --> 00:01:53.090 They'd need to find a Secure Software Assessor who would, 00:01:53.130 --> 00:01:57.790 after evaluating the software, produce a report on validation, or RoV, 00:01:58.320 --> 00:02:01.020 which the software development company would then send to the PCI 00:02:01.020 --> 00:02:05.510 SSC, who would review it, and then list the software on their list of 00:02:05.510 --> 00:02:07.560 approved or validated payment software. 00:02:08.240 --> 00:02:08.780 Finally, 00:02:08.870 --> 00:02:12.580 how about a solution provider that had a point‑to‑point 00:02:12.580 --> 00:02:15.250 encryption solution that they wanted validated? 00:02:15.550 --> 00:02:20.940 The solution provider would employ a P2PE QSA to evaluate the 00:02:20.940 --> 00:02:27.670 solution and produce a P‑RoV, a P2PE report on validation, and that 00:02:27.670 --> 00:02:31.250 will be sent to the PCI SSC, who would review it, and then list the 00:02:31.250 --> 00:02:33.060 P2PE solution on their website. 00:02:33.640 --> 00:02:37.650 So that's how the programs work in respect to the hardware and software and 00:02:37.650 --> 00:02:43.120 solutions where the PCI SSC receives the final report, so they can list the 00:02:43.120 --> 00:02:49.370 product or solution on the PCI SSC website. Now let's have a look at how 00:02:49.380 --> 00:02:54.270 organizations demonstrate their compliance with the PCI standards to each 00:02:54.270 --> 00:02:58.850 other, actually. Standards that apply to how organizations look after payment 00:02:58.850 --> 00:03:05.900 card data include PCI DSS, the data security standard, PCI PIN, the 3DS core 00:03:05.900 --> 00:03:07.140 security standard, 00:03:07.150 --> 00:03:10.760 token service provider standard, and the card production standard. 00:03:11.440 --> 00:03:12.730 In this example, 00:03:12.850 --> 00:03:18.120 one organization, I've called it Organization B, requires another organization, 00:03:18.120 --> 00:03:22.060 say, Organization A, to comply with a PCI standard. 00:03:22.440 --> 00:03:26.960 Typically, Organization B is an acquirer and Organization A is a merchant, 00:03:27.060 --> 00:03:30.440 but it could be that Organization B is the merchant, asking their 00:03:30.440 --> 00:03:34.260 third‑party service provider, Organization A, to be compliant. 00:03:35.240 --> 00:03:39.010 So, Organization A will need to find an assessor authorized by 00:03:39.010 --> 00:03:43.420 the PCI SSC to assess against the standard, and who will produce 00:03:43.420 --> 00:03:46.980 the specified validation document, which Organization A can then 00:03:46.980 --> 00:03:48.460 give to Organization B. 00:03:49.240 --> 00:03:51.360 Let's work through some examples of this. 00:03:51.740 --> 00:03:54.850 Let's start with the most simple example, an acquirer that 00:03:54.850 --> 00:03:58.650 requires their merchant to comply with PCI DSS. The merchant 00:03:58.650 --> 00:04:00.840 engages a Qualified Security Assessor, 00:04:00.840 --> 00:04:04.630 a QSA, who produces a Report on Compliance, or RoC, 00:04:05.000 --> 00:04:06.560 which is given to the merchant. 00:04:06.870 --> 00:04:09.570 The merchant can then provide this Report on Compliance 00:04:09.660 --> 00:04:14.380 to their acquirer. And very similarly, in a three‑party scheme, 00:04:14.510 --> 00:04:17.760 the card scheme requires the merchant to demonstrate its compliance with PCI 00:04:17.760 --> 00:04:22.900 DSS. The merchant hires a QSA, the QSA produces the Report on Compliance, 00:04:22.900 --> 00:04:27.300 which the QSA gives to the merchant, then the merchant can pass on to the 00:04:27.300 --> 00:04:31.730 card scheme that asked them to be compliant. As you'll discover, if you look 00:04:31.730 --> 00:04:33.730 at PCI DSS in more depth, 00:04:33.760 --> 00:04:36.580 it's always the responsibility of merchants to make sure 00:04:36.580 --> 00:04:38.620 their third‑party service providers, 00:04:38.840 --> 00:04:42.750 hosting companies, anyone who provides services that can 00:04:42.750 --> 00:04:45.430 affect the security of cardholder data, those service 00:04:45.430 --> 00:04:48.160 providers also have to comply with PCI DSS. 00:04:49.640 --> 00:04:53.230 So if a merchant requires a third‑party service provider to validate its 00:04:53.230 --> 00:04:57.570 compliance with PCI DSS, the third party will hire a Qualified Security 00:04:57.570 --> 00:05:01.880 Assessor, who will produce the Report on Compliance and give that to a service 00:05:01.880 --> 00:05:05.200 provider. Then the service provider will be able to produce this Report on 00:05:05.200 --> 00:05:08.780 Compliance and give it to the merchant to prove that they are compliant with 00:05:08.780 --> 00:05:14.770 PCI DSS. We'll look at just a few more examples quite quickly. A card scheme 00:05:14.770 --> 00:05:18.800 that requires an acquiring bank to comply with the PCI PIN requirements, in 00:05:18.800 --> 00:05:19.400 this case, 00:05:19.510 --> 00:05:23.840 the assessor that's required is a Qualified PIN Assessor, or QPA. The 00:05:23.840 --> 00:05:28.970 documentation, the assessment, is provided by the assessor to the acquirer, and 00:05:28.970 --> 00:05:33.640 then the acquirer can pass it to the card scheme. And it's pretty similar for a 00:05:33.640 --> 00:05:37.700 card scheme that wants to make sure a card production facility complies with 00:05:37.700 --> 00:05:39.960 the PCI card production standards. 00:05:40.340 --> 00:05:44.120 A Card Production Security Assessor will undertake the assessment, 00:05:44.270 --> 00:05:45.880 produce two Reports on Compliance, 00:05:45.880 --> 00:05:49.240 one for logical one for physical security, and then give them to 00:05:49.240 --> 00:05:51.760 the vendor, who can pass them to the card scheme. 00:05:52.440 --> 00:05:53.070 Finally, 00:05:53.340 --> 00:05:56.160 an acquiring bank might ask a merchant to commission a PFI, 00:05:56.160 --> 00:06:00.930 a PCI forensic investigator, to investigate the cause of a 00:06:00.930 --> 00:06:02.460 breach of cardholder data. 00:06:02.940 --> 00:06:06.940 The PFI will produce the PFI Forensic Report for the merchant to 00:06:06.940 --> 00:06:10.440 give to their acquirer. So, as we've seen, 00:06:10.450 --> 00:06:14.600 each of the PCI standards has an approved assessor and specified 00:06:14.600 --> 00:06:17.160 documents to report the results of an assessment.