2.5 Payment application must protect encryption keys used for encryption of cardholder data against disclosure and misuse.
PCI Data Security Standard Requirement 3.5
Testing Procedures:
2.5 Verify the payment application protects encryption keys against disclosure and misuse, per PCI DSS Requirement 3.5.
[FONT=tahoma,sans-serif]A recent [/FONT]PricewaterhouseCoopers report determined that end-to-end encryption, which encrypts data from point-of-sale at the merchant across the processor’s network, may have the most success at reducing PCI compliance scope for merchants.
While most people tend to associate credit card data theft occurring when that data is stored but not sufficiently protected, the hackers at the front of the data security battle are increasingly intercepting data while it is being sent across networks, relying on packet sniffing malware and SQL injection attacks to breach networks large and small.
End to end encryption helps protect data in transit by ensuring that cardholder data is fully encrypted, across all networks, from card swipe through bank processing. This technology will likely be important for PA-DSS compliance going forward.
It may be worth noting how they used the phrase “reduce scope” which has a specific meaning in PCI speak. The Scope of an assessment is the Card Holder Data (CHD) Environment - that is, the machines, network, people, and software that processes, stores, and transmits sensitive CHD. They did not say reduce risk, or reduce vulnerability, which have a more generic meaning. By reducing scope in PCI speak you are normally referring to something like segmentation to reduce the number of machines that need to be assessed. I know of merchants who have reduced their scope to zero by outsourcing the payment processing to PayFlow via an SSL re-direct so that they never have the payment card info in the clear in their infrastructure.
Yes and this is the most easiest way to get out of the “huge” PCI-DSS-topics because when you outsource anything to a certified PSP then you are allowed to only use SAQ-A which has a very limited scope.
In my eyes each small to medium merchant should try to do it that way with the correct PSP as partner.
Note that a certified Payment Service Provider (PSP) applies to the Visa European region only. Using a PSP in Europe substantially reduces the scope for the under Level 1 merchants.
Really?! Why that?
I thought that using an PCI-DSS compliant PSP for any carddata contact to reduce scope is valid worldwide?
The concept of a PCI certified PSP is only defined in the European region where Visa Europe allows certain Level 3 merchants using a certified PSP to avoid doing any SAQ at all. For all other SAQ eligible merchants, in all other regions*, they must choose the appropriate SAQ based on how and what CHD they process, store, and transmit (or do not). In each of those SAQs that apply to outsourced electronic service providers, the merchant is only required to confirm that the service provider is PCI DSS compliant - i. e., there is no definition of a certified PSP anywhere except in the European region. Now, if you mean to say that use of a PCI DSS compliant service provider to outsource your electronic processing, storage, and transmission can get you into the smaller scope of SAQ A, then I agree with you. Just don’t call that service provider a certified PSP outside of a Level 3 merchant in the European region.
*in Canada, a QSA must “confirm” all SAQs.
This is what I wanted to say 
BTW - for many small-medium merchants, this is the way to go. I was the independent monitor for an FTC settlement following a breach at a software company (they had to implement all of the FTC Safeguard Rule requirements) - their main fix was to simply outsource all payment processing to a service provider. Viola, no more sensitive CHD in their infrastructure at all with a simple https redirect. Since then I’ve advised three not-for=profits to do the same.