Menu

PCI DSS 3.2: Benefits of a ‘business as usual’ approach increasingly in focusFrom 1 February 2018, organisations undergoing Payment Card Industry Data Security Standard (PCI DSS) assessments will need to comply with a number of new mandatory requirements. Although this change under version 3.2 will demand significant attention from many organisations, it also presents an opportunity to benefit from building a culture where robust security is ‘business as usual’ (BAU).

Why the standard is changing?

 
The Payment Card Industry Security Standards Council (PCI SSC) regularly updates the PCI DSS to ensure it continues to protect payment data against a changing threat and payment landscape.

The new requirements introduced in PCI DSS 3.2 were published in April 2016 and are considered best practice until 31 January 2018. From 1 February 2018 they will become mandatory, and the intent of the requirement must be met for applicable card data environments (CDE).

Who is affected?

 
Most of the changes being introduced are aimed at Service Providers, a reflection of the fact that Merchants have increasingly outsourced CDE. The rapid increase in the quantity of data being handled by Service Providers means they are regarded as a growing area of risk.

Merchants should, as part of their own PCI DSS compliance programmes and if not already doing so, ensure their Service Providers have controls in place for the new mandatory requirements, so as not to impact their own assessments.

Given Merchants interact with Service Providers, some of the new requirements will also affect them and they will also need to be confident that third parties they work with are compliant. It is often the case that acquirers will increase charges per card transaction if an organisation is not able to demonstrate satisfactory compliance.

Whilst methodologies such as the Prioritised Approach Template (PAT) can support in reducing those charges over time, in the current climate of economic and political uncertainty, if such charges can be avoided by adopting PCI DSS as BAU then this is recommended.

If an organisation suffers a data breach and customer information is compromised, lack of PCI DSS compliance could see fines levied by card scheme operators against Merchants and Service Providers for loss of data.

The card brand or acquirer may require the compromised companies to fulfil additional PCI DSS requirements to ensure PCI DSS requirements are embedded within BAU activity.

In addition, card data is considered personal information, so Data Protection legislation will need to be observed.

Organisations may also be liable for financial losses incurred against cards and the operational costs associated with replacing the accounts. A serious data breach could lead to loss of confidence among customers, investors, funders and suppliers.

What is changing?  

 
PCI DSS 3.2 emphasises a focus within organisations on people, processes and policies, with technology playing an important role in reducing the overall cardholder data footprint.

The key changes in the latest version are aimed at ensuring that critical data security controls remain in place throughout the year and that they are effectively tested as part of an ongoing security monitoring process, becoming BAU rather than assessment tasks.

A significant change in PCI DSS 3.2 aimed at addressing this is including multi-factor authentication as a requirement for any personnel with administrative access to environments handling card data. Previously this requirement applied only to remote access from untrusted networks.

The requirement now extends to any personnel with administrative access into the CDE, even from within an organisation’s own network.

The change means that organisations will need to examine how they manage authentication into CDEs and review current administrator roles and access.

Service Providers will also need to maintain a documented description of the cryptographic architecture that includes details of all algorithms, protocols and keys used for the protection of cardholder data.

They will need to implement a process for the timely detection and reporting of failures of critical security control systems, including failure of firewalls, anti-virus defences and physical access controls.

Service Providers will also need to respond to failures of any critical security controls in a “timely manner”. Processes must include areas such as restoring security functions, identifying and documenting causes of failure, risk assessments to determine whether further actions are required as a result of the security failure and implementing controls to prevent the causes of failure from reoccurring.

The changes in PCI DSS 3.2 emphasise the importance of validating that security controls are in place and working. There is a new requirement for Service Providers to perform penetration testing on segmentation controls at least every six months and to perform reviews at least quarterly to confirm personnel are following security policies and operational procedures.

Responsibilities for the protection of cardholder data and a PCI DSS compliance programme also have to be established by the executive management of Service Providers.

In addition, from 30 June 2018, all organisations must have stopped using Secure Sockets Layer (SSL) / early Transport Layer Security (TLS) as a security control and use only secure versions of the protocol, although there is an allowance for certain Point of Sale (POS) Point of Interaction (POI) terminals.

Benefits of adopting a ‘business as usual’ approach

 
Many of the changes under version 3.2 are around ensuring organisations have appropriate card data security measures in place as part of their everyday business activities rather than something they just look at for an annual audit.

Encouraging organisations to embed the requirements within a culture which ensures a robust approach to security has always been the aim of PCI DSS, but the changes under version 3.2 mean it is increasingly necessary.

Many of the testing procedures of the new requirements are time dependent and demand that activities are carried out and documented at regular intervals. That means organisations can’t simply look to address compliance issues in the run up to an assessment.

By failing to integrate PCI DSS security processes into daily business procedures and continually monitoring security controls, risk to card data will be introduced.

It represents sound business sense for organisations to make controls part of their everyday business operations. Embedding them in this way means assessment becomes a simple formality rather than having to ensure all the required documents are in place in the run up to an assessment.

Having the right controls in place to comply with PCI DSS can also help organisations save significant time and resources in complying with other requirements.

Given card data is classed as personal data, one set of testing procedures can help ensure organisations have the evidence required for compliance across other required regulation and standards such as the General Data Protection Regulation (GDPR) and ISO 27001

Gemserv and PCI DSS

 
Gemserv’s background in Information Security Management Systems means we have helped many clients move towards PCI DSS as a BAU activity, reducing the strain that assessments place on their internal resources, as well as reducing costs and risk.

Our approach also helps our clients to maintain an ongoing risk reduction framework to help ensure compliance with PCI DSS along with other standards.

Our experience of PCI issues was highlighted during participation at the PCI SSC conference in Barcelona recently, where one of our clients talked about the importance of conducting comprehensive assessment programmes on PCI third party suppliers and Service Providers and the benefits that the assessment programme provides.

We assess the risk around PCI DSS against organisational objectives, reviewing processes and taking into account the wider operational culture, people and processes as much as technology before appropriate controls are considered.

Our Third Party Assessment offering also provides a robust and independent assessment of current and future third party suppliers to protect against potential risks.

Services range from one-off third party risk assessments of a particular supplier or project, through to a fully managed service where suppliers are regularly audited based on risk classification, enabling clients to identify trends and potential issues.

If you would like to hear more about PCI or how we can help, please do contact us on either:

Alternatively you can view the PCI DSS Security Council’s website to find out more.

 

 

Article Author.

Steve Lewis

Principal Consultant - Information Security
Steve is an experienced security consultant and PCI DSS qualified security assessor (QSA), providing advice and guidance to companies in... Read More From Steve Lewis

Our Latest Insights.

Our work means different things to different clients and we wanted to share some details of the projects we have managed to give you an insight into our capabilities and the impact we have delivered as a business.

 

View All Insights

Say Hi.

Did you like what you read? Did you want to find out more about the subject? Or did you simply want to get in touch with us? Either way if you would like to get in touch with us you can do so using the form on the right.

Gemserv will use your details to get in touch with you and to send you information about our products and services that you have requested, in accordance with our privacy policy. You can, of course, opt out of these communications at any time!

Get In Touch

Want to find out more?

Follow the links below find out more about the services we provide, our insight into the industries we serve or the opportunities available with us.
Sectors Capabilities Our Insights Careers