Society of Payment Security Professionals - Payment Security Blog

Compliance of Connected Entities and Third-Parties

Many people have asked “Do you need to audit third-parties?”, “Where does the audit end?”, “Does a connected entity, not able to access credit card data, need to be PCI compliant?”

In a prior post we explained what a “connected entity” was; now let’s get into some of the details. When we ask questions such as those listed above, we are really asking about project scope. You need to understand that in each project the extent to which you measure any of the requirements depends mainly on how you have scoped the project initially.

Do we need to audit third-parties?

It all depends on what services they provide. For example there are two different types of third-parties: (1) those you provide data to, and (2) those you provide access to your data.

• An example in the first category would be an offsite tape backup facility (i.e. Iron Mountain). Requirement 9.5 (v1.0) state, “the off-site storage facility to determine that backup media are [securely] stored” insinuating that the off-site storage facility needed auditing, but the same requirement in v1.1 states, “Verify that offsite storage is visited periodically”. In this case we can see that it is not necessary to audit third parties such as this, but only to verify that they are conforming with the requirement.
• An example of the second category would be if a company outsourced their entire server environment to IBM global services. In this instance, you would need to interview and audit IBM staff and systems to confirm they conform to the PCI DSS compliance standards.

Where does the audit end?

The audit should be properly scoped to only include those systems that store, process, or transmit cardholder data. The scope should also include any connected entities or third-parties, but you can reduce this by firewalling off and restricting access to these companies.

If proper access controls and restrictions are put in place then they can be removed from the majority of the scope (they still need to be addressed in v1.1 requirements 2.4, 12.8, and any requirement designating Service Providers.)

With proper scoping, network architecture, and access controls there should be no need to visit third-party companies and audit them.

Does a connected entity, not able to access credit card data, need to be PCI compliant?

It all depends on how the network architecture and access controls are applied.

Let’s assume a connected entity (third-party) connects to you via a VPN and the policy on the VPN permits them access to only one system, which is does not store any credit card information.

• The problem here is that you have now extended the third-party’s network into yours. In other words, you need to treat the computer that company has access to as if it is an extension of their network. If you cannot do this then you have put a hole in your carefully secured and scoped access controls — which could expand the audit.
• A good solution would be to allow the third-party only access to one application within the computer or only access to a single directory on the computer. This will limit their access within the system and (with constant monitoring and logging of their access) you can limit the scope of the audit.

The rule of thumb is to eliminate business processes that expand the scope of the audit and the cost of compliance. If you can do this your clients/management will be happy and your job will be easier.