Six steps to solving the third party risk management puzzle for PCI

Send to friend

Nick Rafferty, Chief Operating Officer for SureCloud, examines the challenges around ensuring third-party PCI compliance, and outlines a six step guide to success.

Since the Payment Card Industry Data Security Standard (PCI DSS) was first launched in 2004 to help businesses that handle payment card data combat fraud, much has changed in how data is handled, shared and stored, and in response the PCI Council has released its third version of the standard.

One major area of change in how card data is handled by organisations is the increased sharing of data across supply chains. Not only does this expose the data to a much greater risk of loss, it also introduces uncertainty over where the ultimate responsibility lies in protecting the data that is held, stored, accessed and shared throughout the supply chain. One common misconception held by some organisations has been that they can simply outsource PCI responsibilities to a partner in the supply chain that they share data with.

Since PCI DSS version 3.0 it has been clear that businesses cannot outsource their PCI obligation entirely, as the standard spells out that the use of third-party services doesn't exempt an organisation from accountability and its obligation to keep cardholder data secure. This means that when a business partners with third parties, or shares any data related to payment cards, all parties involved must accurately document and monitor their respective responsibilities.


This raises significant compliance challenges for businesses. The flow of information to and from third-party partners and service providers makes it difficult to establish exactly what data is being shared from which departments, who it's being shared with, in what formats, and how it is being used. It's made even more difficult by the fact that all too often, organisations frequently don't know exactly what information they have shared with third parties, and in fact regularly overshare more sensitive data than is actually needed.

Furthermore, there are no agreed international standards for how third party suppliers should be audited, which means a variety of different question sets may be used, depending on the specific regulatory standard, even though the end-result may be similar. So audit data – usually a collection spreadsheets – comes back to organisations in different formats from each supplier, to be processed manually by small teams for whom external risk and compliance assessments may not be their main function. Then each third-party needs to audited individually to understand the risk it exposes the organisation to, and all third parties assessed collectively to identify which poses the most significant risk.

This complexity makes the assurance process extremely time- and labour-intensive, both for those doing the assessing and those being assessed: in many cases reducing it to a tick-box exercise that is inefficient and exposes organisations to risk. So how can third-party risk management processes for PCI compliance be simplified and made more effective, to mitigate the risks of data breaches, losses and penalties? I believe there are 6 keys steps to achieving this.

1. Classify information

All too often organisations don't know what information needs to be protected, what data is covered by various laws and regulations or what Personal Identifiable Information is – let alone what data is covered by PCI DSS. So to start the process of maintaining PCI compliance when working with third parties, it's critical to classify which data is covered by the PCI standards, all the locations it is stored in, and which parties have access to it.

Data is usually classified into three broad categories: 'Confidential,' which refers to sensitive information that qualifies for the highest degree of protection, usually covered by a signed confidentiality agreement; 'Internal,' which is data not meant for public disclosure, but freely available to all employees, such as company policies and standards, operational procedures and so on; and 'Public,' which is not governed by special protection measures.

2. Rating 3rd parties

Once data is classified, you can start to identify which partner organisations have access to which types of data, and in turn where the greatest risks to your information assets are. You need to know what data of yours is held by partners and suppliers alike, and who they are sharing it with. In many cases, it's useful to start this process by asking partners what information they actually receive from you; as I mentioned earlier, in many instances we've seen organisations oversharing information, simply because staff are pressed for time, and may not always take the trouble to filter the data they send. By asking your third parties, you can quickly get a more accurate picture of your exposure.

3. Ask the right questions

Having classified both your data and your 3rd parties, you're ready to start assessing them. But it's important to ask the right questions. PCI compliance audit questionnaires are wide-ranging but the sections which are relevant to each third party will depend on the role they perform for you (e.g. do they provide marketing services, or manufacture for you, or provide a business service). By asking only the questions which are relevant to the specific partner, you accelerate the process, get better quality results and ultimately save yourself time: making it easier to understand your risk posture.

4. Automation, automation, automation

In many organisations, compliance processes are run using manual, spreadsheet-based systems. These rapidly become unworkable with any significant number of 3rd parties; the process of assessment and identifying issues is simply too time-consuming, making it difficult to properly manage compliance activity and exposing the organisation to unknown levels of risk. As such it's critical to automate the process, using an IT framework that gives:

  • A centralised structure and dashboard for efficient programme management
  • Assessment templates based on common control standards (including PCI DSS)
  • The ability to create multiple versions of assessments for different 3rd parties
  • Automated tasks and workflow to track compliance activity
  • Analytics capabilities for reporting to external and internal stakeholders

5. Break the annual cycle

Many organisations treat PCI compliance as a one-off tick box exercise to be done on an annual basis, assuming that this means they will meet the standard for the next 12 months. The reality, however, is that an audit simply means a business is compliant at the moment the assessment was completed. Policies and relationships change, and so remaining compliant is a continual process. It's the difference between passing your driving test, and being a good driver. By working to ensure continual 24/7/365 compliance, organisations will reduce the risks of them and their supply chain falling short of PCI standards.

6. Course corrections

Having established your third-party risk management process and identified any potential or actual risks, don't forget to take the necessary remedial actions with the appropriate partners. Depending on the scale of the risk, either don't share data with them until the situation is resolved, or give the partner a deadline by which to correct the identified issues. And continue to follow up with partners, to ensure your assurance programme is effective in reducing your risks over time.

While third-party risk management will never be a simple task, these six steps can help organisations make it a great deal easier to perform and manage – which helps to better protect themselves, and their customers, against security risks.

About the author

Nick Rafferty is co-founder and COO of SureCloud. Prior to founding SureCloud, Nick held roles in software development and programme management, delivering applications to improve supply chain efficiencies in retail, banking and finance. Today, Nick oversees SureCloud's operational activities, from sales through to service delivery and contributes to developing the SureCloud GRC Platform.

Comments (0)

Add a Comment

This thread has been closed from taking new comments.