For more information contact us on:
T:0118 948 2588
E:enquiries@ackltd.co.uk
------------------------------------
PCI DSS
The ACK solution >More
The ACK solution diagram >More
PCI
background >More
Frequently
asked questions >More
Information resource >More
Glossary of terms used within PCI >More
Why acronyms cost retailers money >More
PABP
Information resource on Payment Application Best Practice >More
Why acronyms cost retailers money
And why retailers need to understand PCI DSS and PABP
As we all know, a new acronym from the payment industry usually means there will be a cost and retailers are weary of spending more money just so they can accept plastic money.
EMV = PIN pads = £lots
APACS CC = new PIN pads = £lots more
3DSecure = new software = £lots
PCI DSS = new security = £unlimited
PABP = what is this? = £unknown
The first two items are firmly the responsibility of the payment card hardware and software vendors – they are the ones who have been obliged to ensure their products conform to the requisite standards: The retailers don’t need to know the detail, just be assured that the equipment and software they use has the relevant accreditation.
The fourth and fifth would also seem to be the responsibility for the payment card hardware and software vendors, but this is only partially true.
PCI DSS - It is true that managed payment service providers must have their service and procedures audited to ensure compliance, but it is the retailer who is obliged to ensure their own data communications network, EPoS, back office and head office systems satisfy the regulations whether they use a payment service provider or not. It is a myth spread by some managed payment service providers that using their services absolves the retailer from the burden of PCI DSS. This mis-information is doing the payment industry and the retailers a disservice – when retailers realise that they are still responsible for proving compliance with the PCI DSS regulations, they rightly doubt the honesty of those managed payment service providers who have glibly told them that moving to a managed service (theirs) will ensure the retailer will avoid the cost of gaining and maintaining PCI DSS compliance.
This is simply not true - the retailer MUST:
Have a vulnerability check run on their data communications network regularly.
Ensure hardcopy receipts on which full card numbers are shown are both stored and disposed of securely.
Ensure their systems do not hold sensitive data in clear – these include, but are not limited to:
- EPoS
- Back Office
- Head Office
Failure to comply will be dealt with harshly – any compromise traced back to the retailer will bring the retailer to the attention of the regulatory bodies who will impose punitive fines if a compromise is found to be due to non-compliance. PCI DSS audits are therefore a must for all retailers.
There is a moral issue here too – preventing even minor fraud is a civic and socially responsible duty as it helps curb crime. Crimes involving card data can be petty and low level to highly organised, international and often used as funding for greater crimes such as those involving drugs. At any level it amounts to massive losses for all concerned: the cardholder, the retailer, the acquirer, the card issuer, the card scheme.
What should a responsible retailer do?
The first stage is to understand the problem. This can be achieved by reading the relevant documents to determine which category a retailer falls into. The next stage may be to engage an auditor qualified to identify and assess the vulnerabilities of a retailers’ system. In fact, a well managed IT department will probably have most of the appropriate protection, processes and procedures already in place, although card data encryption might not be one of them.
The retailer must also check that the payment application they use conforms to with Payment Application Best Practices (PABP). These are currently voluntary, but are being ratified by the governing council (PCI Co) who will shortly announce that all payment applications must be certified to this standard, renamed Payment Application Data Security Standard, PA DSS.
So, the answer is simple: buy payment application software which meets PABP standard and job done. Err, not quite - it is highly likely that retailers do not know the true extent of where sensitive data might be stored within their various computer and paper systems – and if they do manage to remove this data, what other business processes depend on this data and are likely to fail if the data is not available. For example, loss prevention systems need to hold card data for long periods of time if they are to be used as evidence in prosecution cases.
So what is the answer?
Find a solution which fits in with the current system architecture without imposing a complete overhaul.
This is where ACK can help. We have been working hard to ensure our payment application software does satisfy PABP requirements. Much of the work affects the internal workings of how sensitive data is used and, more importantly, stored – these functions do not affect the fundamental functions of the software, nor the interface to the EPoS system. ACK are therefore able to offer our existing users a simple upgrade path which does NOT require re-certification of the chip and PIN components. ACK have also elected to use the crypto-API which is available for most Windows operating systems. This approach avoids the need for costly hardware security modules and is suitable for deployment in single-site or multi-site installations. For multi-site installations, ACK offer a utility which enables encryption keys to be generated and managed centrally and used across the estate.
Furthermore, ACK can provide access to the encryption algorithm which allows other processes not directly related to the payment application to include encrypted card data within their data storage areas without falling foul of PABP or PCI DSS regulations. For example, card data might be included in the transaction logs recorded by the EPoS system and used by central processes for reconciliation or other purposes. Removal of the card data might not be practicable, or cause unexpected and undesirable affects in other parts of the system. Therefore, substituting card data stored in clear with encrypted card data, the up-stream processes should be unaffected and might not require any modification. However, for up-stream processes which do have a legitimate need to access card data, this data may be decrypted, but of course will then become within scope of the PCI DSS regulations.
So, is there a simple answer?
Yes, select ACK as your payment application provider - we not only understand the problems, but we have solutions to the problems.