TPSPs score goals and save money!

Protecting sensitive information has become a vital aspect of running any business, and one area that requires a high level of vigilance is payment security, especially for businesses that handle credit card (also known as cardholder) data. These businesses must adhere to the Payment Card Industry Data Security Standard (PCI DSS v4.0), complying with a set of stringent guidelines that is maintained by the PCI Standards Security Council (SSC). It’s not all work and no play however and as we’ll describe below, by following particular directives from the PCI DSS and employing TPSPs with an Attestation of Compliance (AOC), merchants really can “score goals and save money”.

The PCI DSS applies to all businesses that accept, process, store, or transmit credit card (also known as cardholder) data. The DSS refers to those businesses as “merchants” or “assessed entities”, so we’ll use the term “merchant” in the rest of this article.

And we’ll use illustrations of rabbits as cheery visual analogies. Read on!

All businesses that accept, process, store, or transmit cardholder data (CHD) must meet the requirements of the PCI DSS, and meeting those requirements requires merchants to address up to 251 controls across 12 requirements.  This can be challenging enough but merchants who utilise the services of a Third-Party Service Provider (TPSP) need also to consider :

  • PCI DSS 4 Requirement 12.8, which states that the merchant must ensure that risks to information assets associated with third-party service provider (TPSP) relationships are properly managed.

  • PCI DSS 4 Requirement 12.9, which states that third-party service providers (TPSPs) must support their customers’ PCI DSS compliance.

The aim of these controls is to ensure that the merchant maintains explicit and important documentary records, while also emphasising separation of duties and a sense of shared accountability with its TPSP for preserving data security.  But a consequence of these controls is that the merchant needs to manage its TPSPs in order to ensure the merchant’s ongoing compliance, and to help ensure the ongoing security of the merchant’s business.

As you can imagine (and as we’ll describe in detail below) complying with Requirement 12 can be a right pain, but the merchant’s compliance goals can be made A LOT less painful if they use TPSPs who are also compliant with the PCI DSS, especially if those TPSPs can prove their compliance by producing an Attestation of Compliance (AoC).

What is an Attestation of Compliance (AoC)?

A Third Party Service Provider (TPSP) Attestation of Compliance (AoC) is a declaration, provided by the TPSP, that confirms that the TPSP has implemented specified controls from the PCI DSS. An AoC can be issued following a successful audit conducted by a Qualified Security Assessor (QSA), or created by the TPSP following a self-assessment against one of the Payment Card Industry (PCI) Self-Assessment Questionnaires (SAQs). 

An AoC includes details about the TPSP’s name, the version of the PCI DSS they were audited against [2], which requirements were tested and found to be in place and which were not applicable. This comes in real handy when the merchant goes to report on PCI DSS v4 control 12.8.5, which states that a merchant must maintain information “about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.”  If a TPSP can hand over an AoC, then complying with 12.8.5 is a doddle because the AoC provides the merchant with assurance that the TPSP has implemented all of the PCI DSS controls for which the TPSP has agreed to be responsible.

Supply chains and the role of TPSPs in compliance

Supply chain attacks have been in the headlines over the past year with some notable examples including:
  1. The ongoing MOVEit  saga.

     

  2. The 3CX PABXaaS breach.

     

  3. The PyTorch software supply chain attack. 

Of particular relevance here however (because of the PCI DSS-related aspect) is the 2013 Target (US) data breach, one of the most notable data breaches in history, which occurred because of a vulnerability and subsequent breach of the network of one of Target’s TPSPs. The attackers behind this attack exploited a weak link in the TPSP’s network to gain access to Target’s network, and then engineered an attack on Target that resulted in the theft of over 40 million credit and debit card records, as well as personal information of 70 million customers. 

Estimates as of 2023 suggest that attack will eventually cost Target around $300M once all is said and done.  Clearly then, if only from a financial perspective, it is important to ensure that TPSPs are not the weak link in the data security chain, especially because they may be responsible for almost any aspect of a merchant’s cardholder data environment, from payment processing to storage, and from WAFs to VOIP services.

The PCI SSC recognises this fact and so the DSS includes the note: 

“Service providers are responsible for demonstrating their PCI DSS compliance, and may be required to do so by the payment brands. …There are two options for third-party service providers to validate compliance:

1) Annual assessment: Service providers can undergo an annual PCI DSS assessment(s) on their own and provide evidence to their customers to demonstrate their compliance; or

2) Multiple, on-demand assessments: If they do not undergo their own annual PCI DSS assessments, service providers must undergo assessments…

…The specific type of evidence provided by the service provider to their customers will depend on the agreements/contracts in place between those parties. For example, providing the AOC and/or relevant sections of the service provider’s ROC (redacted to protect any confidential information) could help provide all or some of the information.”

AOCs save you money!

The PCI DSS game is a carrots and sticks affair.  

And my, what sticks!  The consequences of PCI DSS non-compliance can be severe and can result in hefty financial penalties (thousands to millions of dollars) levied by the card brands. But the monetary impact only scratches the surface. If a data breach takes place, merchants could face additional costs in the form of forensic investigations, mandated reporting, remediation activities, and possibly even litigation. And then of course there is negative impact on the merchant’s brand which, while not related directly to the PCI DSS, we see in current breach incidents such as those involving Latitude Financial Services, HWLE, Latitude, Medibank, and Latitude.

But don’t be a glum bunny because along with the sticks there is the TPSP AOC carrot… well, three big carrots, actually! Here’s how a TPSP AOC can make a great deal of merchant compliance pain just go away:

  1. The AOC is a preventative measure.  As we noted above, Requirement 12.8 of PCI DSS states that the merchant must manage their TPSPs. If this is done well, then the merchant can be confident in their TPSP’s level of security maturity, and that in turn reduces the risk of breach to the merchant. There are lots of ways that a merchant can verify the level of maturity of their TPSPs. However, in the context of the PCI DSS, the AOC provides a clear statement regarding the PCI DSS controls for which the TPSP is responsible and so (when read within the context of a Responsibility Allocation Matrix or RAM) it therefore provides a great deal of certainty from a preventative perspective.

  2. The AOC is a cost and stress-saving measure.  If the TPSP can present an AOC to the merchant at merchant-reporting time, then as long as the AOC is complete and consistent with the RAM, nothing more needs to be done. The merchant just needs to sort out the PCI DSS requirements for which the TPSP is not responsible, hand in the AOC for the controls that the TPSP is responsible for, and that’s it!

    Compare that to the scenario where the TPSP does not have an AOC: As described in the PCI DSS, if the TPSP does not have an AOC then they must “undergo assessments upon request of their customers and/or participate in each of their customer’s PCI DSS reviews, with the results of each review provided to the respective customer(s)”  Now, trust us; from a merchant’s perspective, this is a no-win situation!  In fact it can be so bad that we’ve included a whole section on it below!

  3. The AOC may be a lifeboat if the seas should get rough and the merchant should be breached.  Note clearly here that DotSec is not a law firm and each jurisdiction is different, but if the merchant suffers a breach associated with one of the controls that was included in the TPSP’s AOC, then the PCI SSC and the class action lawyers may decide that the fault lies with the TPSP and not the merchant. This assumes of course that the merchant has an up-to-date RAM and that the TPSP’s AOC was verified (as described in the following section) by the merchant to ensure that the relevant PCI DSS requirements were examined and determined to be in place. 

“Well heavens!”, said Mr Rabbit, “Who would have thought that one document could be so useful in so many scenarios?”

The process of verifying a TPSP AoC

Verifying a TPSP’s AOC may seem daunting, but it’s a straightforward process when approached methodically.  Here’s how a merchant would do it:

  1. Request the AoC: The first step is simply to ask the TPSP for their most recent AoC. Reputable providers should be willing and able to provide this.

  2. Review the AoC: Once you have the AoC, check the document’s key details. These include the provider’s name, the PCI DSS version against which they were audited, the scope of the assessment, and the date of the assessment.

  3. Check the coverage: Ensure the AoC covers all services the provider is offering to you, and is consistent with the RAM and any other TPSP agreements or contracts. Sometimes, a provider may have multiple services, but not all of them are PCI DSS compliant.

  4. Monitor regularly: Lastly, remember that AoC is not a one-time document. Regular monitoring is key, as providers need to maintain their compliance and get re-audited regularly. Make sure you are aware of when your provider’s AoC expires, and ensure they are re-audited and a new AoC is provided in a timely fashion.

Pretty straightforward, right?  But what if the TPSP has no AOC?  Ah well, that’s a much darker tale… Read on, and see just how deep the rabbit hole goes!

“No AOC!”, said Mr Rabbit, “I think we’re in trouble now!”

The process of monitoring a TPSP that has no AOC

As we noted above, sometimes a merchant will not be aware of the intricacies surrounding PCI DSS TPSP management and will find out (probably at assessment or reporting time) that their TPSP does not have an AOC. From what we’ve seen over 11-ish years, this is often a no-win situation for the merchant. As part of the monitoring a third party TPSP without an AoC, the merchant needs to review the controls that have been implemented by the third party TPSP and here is how that happens:

  1. Evidence Request: The merchant should request the TPSP for detailed evidence of the implemented controls that the TPSP is responsible for. This could include security policies, procedures, system architecture diagrams, risk assessments, and associated documentation.

  2. Detailed Review: Assuming the TPSP provides the required evidence, that evidence should be reviewed to determine whether the implemented controls meet the requirements of the PCI DSS for which the TPSP is supposed to be responsible. This review should be conducted by someone with sufficient knowledge and experience to understand the controls and how they relate to the PCI DSS.
  3. Independent Assessment: Depending on the risk associated with the TPSP and the complexity of the controls, the merchant should consider an independent assessment conducted by a Qualified Security Assessor (QSA) or other qualified professional. Yes, that can be expensive but as we noted above, the consequences of getting it wrong can be even expensiver! [1]

  4. Documentation of Results: The results of the review, including any identified gaps and actions taken to address them, should be documented by the merchant organisation. This is because the PCI SSC may ask the merchant to report on the TPSP’s level of compliance.

  5. Continuous Monitoring: The merchant organisation must continue to monitor the TPSP’s controls on an ongoing basis. This could involve regular reviews of the evidence they provide, as well as regular communication with the TPSP about any changes to their controls or security practices. Remember, Requirement 12.8.4 states, “Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.”
All of this of course requires the agreement and collaboration from the TPSP but from what we’ve seen over the past decade or so, the TPSP will often either:
  1. Want to charge the merchant for the time and effort they incur addressing the above tasks, and for the assessment that the TPSP needs to undertake in Step 3 or,

  2. They’ll just refuse to cooperate and claim that “because they don’t accept credit card payments, the PCI DSS is not relevant and they don’t need to play along”. [3] 
At this point, the merchant gets to choose whether to pay for all of the monitoring activities (assuming the TPSP will cooperate), submit an incomplete report to their acquirer and wait for the blow-back, or renegotiate with another TPSP who will play according to the PCI DSS rules, with all the time and cost that entails. Either way, at around this time, the merchant is probably wondering if heavy drinking is a valid option, and is certainly going to wish they’d engaged with a TPSP who had an AOC!

Navigate PCI DSS compliance with DotSec

Merchants are ultimately responsible for ensuring the security of the cardholder data that they collect, store, process and transmit, but merchants can save time, cost and stress by choosing TPSPs that will collaborate in meeting this critical responsibility. And the easiest (cheapest and least time-consuming) way of doing this is to choose TPSPs who can produce an AOC that aligns with the merchant’s RAM and other TPSP contractual agreements. 

Navigating the tricky landscape of payment-card security can be intimidating, but taking a proactive approach to maintaining compliance, both internally and with third-party providers, is key to preserving customer trust and business longevity.

Given the complexities and high stakes of non-compliance with PCI DSS, many businesses find it beneficial to seek professional assistance. At DotSec, we offer expert guidance and support in PCI DSS compliance. Our services range from explaining the nuances of PCI DSS to providing comprehensive compliance preparation and/or assessment.

DotSec can assist you in fostering and maintaining your customer’s trust and your business’ compliance with the PCI DSS. Contact us today for a thorough review of your PCI DSS procedures and to learn how we can bolster your data security framework. Let’s transform payment security from a painful burden, into a key strength of your business. 

Go on!  Reach out to DotSec for all your PCI DSS service needs. You know you want to!

Bye for now, and thanks for reading!
[1] Yes, I know expensiver is not a real world. We’re writing about PCI DSS for heaven’s sake; gotta lighten it up somehow!

[2] This can be either v3.2.1 or v4 until March 31 2024, after which time v3.2.1 will no longer be acceptable.

[3] Seriously, this happens more often than not.  Even national and multinational service providers (think Telcos, PaaS providers and Managed Security Service Providers) get it wrong and don’t understand that as service providers, they have responsibilities to their merchant customers.  It’s really no different than the service provider requirements that exist for APRA’s CPS 234 but none-the-less, it’s often a complete blocker when it comes to compliance and reporting time.