Third Party Service Providers And PCI Compliance

There seems to be a lot of confusion regarding third parties that provide networking or hosting services and their obligations regarding PCI compliance.  This confusion is not uncommon as merchants and their service providers have not necessarily been provided enough guidance to understand their obligations.  I hope this post will clarify those obligations for all involved.

If you learn nothing else from this post, if a third party is providing your organization a service that has access to your cardholder data environment (CDE) or the third party could come into contact with your cardholder data (CHD), then that third party must ensure that the service complies with all relevant PCI requirements.  As a result, the third party needs to either allow you or your QSA to assess the services that they are providing or provide you with an Attestation Of Compliance (AOC) that documents that those services have been assessed and they are PCI compliant.

In the past, I have stated that third parties could also submit a letter signed by an officer of the third party stating that all of the services provided to their customer are PCI compliant.  Now that v2.0 of the PCI DSS has a separate AOC and the PCI SAQs have the AOC built into the SAQ, there should be no reason to need such a letter or to ask for one.  If a letter is what your third party is offering, it is better than nothing, but you should be pushing them hard for an AOC.  If they are reluctant to get you an AOC, as part of your vendor management process, you should take that into account and probably begin looking for a new vendor that will provide an AOC for their services.

The most common issue we run into with third parties is that their AOC or other representations of PCI compliance do not cover all of the services provided to the customer.  In case after case, we see the AOC covering requirements 9 and 12 and nothing else even though the services provided may require compliance with some or all of PCI requirements 1, 2, 3, 4, 5, 6, 7, 8, 10 and 11.

In a lot of cases, it is not that the third party does not want to comply with PCI; it is they are taking the lowest common denominator approach and only picked those services where all customers requiring PCI compliance are asking for an AOC.  That way they have reduced their costs of a QSA to assess their environment.  These third parties are accepting the fact that any customer that needs more services assessed will have to do it themselves.

Related to this issue is the third party that offers their SSAE 16 Service Organization Control (SOC) 1 report has proof of PCI compliance.  While a SOC 1 report can cover a few PCI requirements, people must remember that the SOC 1 report is structured specifically for financial auditors to ensure that the controls at a third party are properly constructed to support financial reporting at the customers.  As a result, a SOC 1 report is not going to be a substitute for an AOC that covers all services.  There is an alternative to this and that is to have the third party go through a SSAE SOC 2 report that focuses on the security controls of the PCI in-scope services provided.  We are hearing from third parties inquiring into the SOC 2 report, but cost and a lack of customers requesting such a report are driving why we do not see more SOC 2 reports available.

Another common issue we encounter is the refusal of the third party to cooperate in assessing the services provided to ensure they are PCI compliant.  There are still third parties that argue their services are not in-scope for PCI compliance even when it is painfully obvious that the third party’s personnel have access to their customer’s CDE and/or CHD.

The most common third party relationship we encounter is the management of routers or other layer 3 devices.  Where we encounter the most confusion in this relationship is in regards to the use of encryption to keep the network services organization out of scope for PCI compliance.  The key here is if the network services organization manages the encryption of the network, then they are in-scope for PCI compliance.  The reason is that the employees of the network services organization have access to the encryption keys and therefore could decrypt the communications and gain access to CHD transmitted over the network.  As a result, at a minimum, the network services organization is responsible for complying with some or all of requirements 1, 2, 4, 6, 7, 8, 9, 10 and 12.  If you receive such services and are not getting an AOC that covers these requirements, then you should be doing more work on your own as well as asking the third party why they are not covering more of the necessary PCI requirements.

The next most common service we encounter is the network services firm that is managing or monitoring an organization’s firewalls, remote access or intrusion detection/prevention.  Such services always put the third party in-scope for PCI compliance.  Some or all of requirements 1, 2, 6, 7, 8, 9 and 12 will need to be assessed for compliance with the PCI DSS.  The log capture and analysis requirements in requirement 10 may also be complied with if your organization is not capturing and analyzing the log data from these devices.

Another group of third parties we encounter a lot are records retention vendors.  Organizations like Iron Mountain have conducted their own PCI compliance project and readily hand out their AOC to customers.  However, where we see issues is with such vendors that provide their own tape library for their customers to use for backup.  We have encountered a number of third party’s doing the encryption at their library which puts them in-scope for PCI compliance, at a minimum, for requirements 3, 4, 6, 7, 8, 9, 10, 11 and 12.

We encounter outsourcing the data center a lot with large organizations, but small and mid-sized organizations are also hopping on the data center outsourcing bandwagon.  Where this puts the third party in-scope for PCI compliance is when the third party is responsible for maintaining the environment such as applying patches, managing servers or any other activities that would allow the third party’s personnel to potentially have access to CHD.  In such situations, at a minimum, the third party is responsible for complying with some or all of requirements 2, 5, 6, 7, 8, 9, 10 and 12.  Compliance with some or all of requirement 1 may be applicable if the third party is managing your firewalls or routers.  Compliance with some or all of requirements 3 and 4 may also be applicable if the third party is responsible for managing encryption keys for encrypting CHD or encrypting communications.

Where the most confusion regarding third party responsibilities occurs is in regards to “The Cloud.”  The most common reason for this is that every vendor seems to have a different definition for what “The Cloud” is, based on their particular services.  Using the definitions provided by the National Institute of Standards and Technology (NIST) in their publication SP800-145, ‘The NIST Definition Of Cloud Computing’, I can provide the following guidance.

If your organization is purchasing Infrastructure as a Service (IaaS), then the third party providing these services will typically be out of scope for PCI compliance except for requirements 9 and 12.  There are some instances where IaaS implementations may require compliance with the PCI DSS if the third party is managing network infrastructure that comes into contact with CHD as is usually the case with private cloud environments.

For Platform as a Service (PaaS) and Software as a Service (SaaS), the third party will have to provide PCI compliance for the services they are providing to your organization.  That is because with either of these service offerings, the third party must have access to the CDE and will have the potential of coming into contact with CHD.

The problem with the majority of PaaS and SaaS vendors is that they only deal with your organization through a Web-based interface, i.e., everything is automated – contracts, support, etc.  As a result, the contract is a “take it or leave it” situation that does not usually cover everything needed for PCI compliance, there is no way to independently verify the representations made by the third party as well as the fact that the AOC provided by the third party typically only covers only the physical security requirements in requirement 9 and possibly some of requirements 11 and 12 and nothing related to the other requirements, even though the third party may have responsibilities for PCI compliance outside of what is represented in their AOC.

If this is the case, there is little you or any QSA can do to properly assess the environment to ensure it is truly PCI compliant.  As a result, we have a lot of organizations that try to develop compensating controls for these cloud implementations.  These organizations very quickly and frustratingly find out that there are very few, if any, controls on their side of the equation that can get them to “above and beyond” the original requirement.

I know there are a lot of other examples of services being provided to merchants.  But, hopefully these examples can assist you in clarifying what you need or do not need from your third parties when it comes to PCI compliance.

SAS 70 Is Dead!

Long live SSAE 16 and ISAE 3402!

One of the most misunderstood things about SAS 70 was the fact that it was technically only a valid auditing standard in the United States, even though SAS 70 reports are done for non-US based service providers and are relied upon by businesses and auditors worldwide.  However, on or before June 15, 2011, that will change.  As of that date, Statement on Standards for Attestation Engagements (SSAE) 16 and International Standards on Attestation Engagements (ISAE) 3402 will replace the venerable SAS 70.  SSAE 16 is issued by the American Institute of Certified Public Accountants (AICPA) and ISAE 3402 is issued by the International Federation of Accountants (IFAC).

The good news is that, for the most part, SSAE 16 and ISAE 3402 are essentially the same.  There are a few differences that are important to financial auditors and lawyers, but should not have an impact on people relying on these reports for PCI compliance or other purposes.  What is important is that now, no matter where you are in the world; you can obtain an independent assessment of a service provider’s controls.

There are three different types of AICPA Service Organization Control (SOC) reports.  The SOC 1 (Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting) is what SAS 70 is now referred to and is conducted to the SSAE 16 standard.  The SOC 2 (Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy) and SOC 3 (Trust Services Report for Service Organizations, formerly known as WebTrust) are conducted to Attest Engagements section 101 standards.  The AICPA has indicated that SOC 1, SOC 2 and SOC 3 reports have to be issued as separate reports.

For PCI and other IT or non-financial purposes, the SOC 2 report is the one that should provide you the most benefit as it can include controls relevant to security, availability, processing integrity, confidentiality and/or privacy.  SOC 2 reports must use all or a complete subset of the SOC 3 principles.  While not ITIL, HIPAA, PCI or such, they should be more than adequate to ensure an organization is conducting business to ensure appropriate practices.   Best of all, as with the SOC 1, the CPA firm can issue an opinion as to whether those controls are functioning as designed.  Why is an opinion important?  Because the CPA firm has conducted testing over a given period of time (usually six to 12 months) to ensure that the controls tested functioned as designed for the period of time being audited.  ISO and PCI certifications do not provide such assurances as they are as of a certain date not over a period of time.  Although I understand that ISO is considering changes to their processes that may change their certification processes to be similar to SOC 2.

Unfortunately, financial auditors outside of the United States are, for the most part, unfamiliar with conducting such an assessment of controls.  As a result, they will need time to get up to speed on such attestation engagements.  So those of you outside of the United States need to be patient while the auditors in your country get up to speed.

Guidance on SOC 1 and SOC 2 reports need to be structured is expected by April 2011.  So please do not bug your friendly CPA until after April 2011 regarding these new reporting standards.  The bottom line is that we are expecting to see a lot of SOC 2 reports that will cover ITIL, HIPAA and PCI requirements as part of their testing.  So start asking your service providers now for an SSAE 16 or ISAE 3402 report now so that your service provider can start asking their auditor to prepare such a report.

SAS 70 and PCI

One of the most misunderstood standards is the American Institute of Certified Public Accountants (AICPA) Statement on Auditing Standards number 70 (SAS 70).  I intend to explain this standard and show how it can be applied to the PCI compliance process.

It is important to understand that the SAS 70 is a financial accounting standard and is considered an attest service in the audit community.  As an attest service that means that the auditor issues an opinion regarding the control environment.  This attestation is not a certification such as those an organization gets for ISO.  The SAS 70 standard was developed so that financial auditors did not have to go out and conduct an audit of every outsourcer that a client might use.  This saves the outsourcer of having multiple audits conducted mostly in the last quarter of the year.  However, being a financial audit standard, it does not have to cover everything that you will need to complete your PCI compliance process.  Even with the SAS 70 report, you will likely have to go back to the outsourcer with additional questions.

A key point about SAS 70 is that there must be a material financial impact to your company in order to justify a SAS 70 report from an outsourcer.  This is why outsourcers such as those that process your organization’s payroll or serve up your financial software will have a SAS 70, but your telecommunications provider or the company that monitors the security of your facilities likely does not have a SAS 70.  As a result, not every outsourcer will have to provide your organization a SAS 70 report.

A SAS 70 can come in two varieties, Type I and Type II.  A SAS 70 Type I report only attests to the description of the outsourcer’s control environment.  The auditor conducts no independent testing of the control environment and therefore does not express an opinion on whether or not the control environment is functioning properly.  For PCI compliance a Type I report is worthless, as you need the testing to have any chance of using the report.  A Type II report will have a section devoted to the tests that were conducted to confirm that the control environment is functioning properly and the outcome of those tests.  However, since the testing in a Type II report will be focused on key financial controls that do not necessarily involve PCI, a Type II report may also be worthless to your PCI compliance efforts.

Just like its financial audit report brethren, there is a correct way to read a SAS 70.  The first thing you should read is the cover letter to the report, otherwise known in auditing circles as the opinion letter.  The opinion letter will tell you the locations reviewed, the time span of the report, whether the report is a Type I or a Type II and whether or not there were material issues found during the audit.

The locations reviewed are very important.  If your organization is hosted out of the outsourcer’s data center Q and it was not reviewed in the SAS 70 report, then you need to get the SAS 70 report that covers data center Q.  Unlike the PCI ROC, which covers an organization’s compliance at a given point in time, a SAS 70 report is for a period of time known as the opinion period.  The opinion period can be as little as three months and typically as much as 12 months.  Most SAS 70 reports are for opinion periods of six to 12 months.  For financial auditors, they can only accept SAS 70 reports that cover all or part of their audit client’s financial audit period.  For PCI compliance, it is up to you to determine if you are willing to accept the SAS 70 report.  If you have a QSA conducting your assessment, it is up to the QSA to accept the report.

The opinion letter will not expressly use the terminology of Type I or Type II.  To determine the type of SAS 70 report, you will need to read the letter and look for where it says, “We did not perform procedures to determine the operating effectiveness of controls for any period” or similar wording.  That will indicate that the report is a Type I and is not usable for you PCI compliance.

There are three opinions that an auditor can provide; unqualified, qualified and adverse.  An adverse opinion is the worst and means that the control environment is not operating as designed and the controls cannot be relied upon.  I have never seen an adverse opinion ever publicly issued, but you need to be aware that it does exist.  A qualified opinion means that some controls are not operating as designed.  The opinion letter will document those controls that failed and why they failed.  The best opinion, unqualified, means that the control environment is functioning as designed and that none of the controls failed testing.  Remember, just because an outsourcer gets an unqualified opinion, does not mean that the controls operate that way all of the time.  It just means that the auditor through their testing techniques was not able to observe any conditions that would indicate that the controls were not functioning.  The phrase ‘reasonable but not absolute assurance’ is how auditors refer to the ability of their testing to detect any flaws in the control environment.  What this means is that they construct their tests such that there is a high likelihood that any flaws in the controls can be detected, but that these testing procedures are not perfect.

Once you have read the opinion letter, you need to read the testing section to see if the controls that you need for your PCI compliance were tested and if the tests are ones that are relevant to your PCI compliance.  The most common tests that everyone needs are related to physical security and environmental controls at the data center. All of these are necessary for all outsourcers.  Additional control testing will be required if your outsourcer provides services beyond just housing your technology, so you will be interested in controls surrounding those additional services.  Many organizations are now adding PCI, Gramm Leach Bliley Act (GLBA) and Sarbanes Oxley (SOX) tests to their SAS 70 reports to help their customers meet the majority of their compliance requirements.  This is a relatively new practice and the adding or changing tests can radically affect the price of an organization’s SAS 70 report, so it is still rare to find many of the controls tested for these other compliance areas.

When reviewing the control tests, the auditor will usually mark the test as “No Relevant Exception Noted” if the test was passed.  In cases where an issue was noted, the issue will be documented.  If the issue is determined to not be systemic, it will typically be noted in the testing notes and will not result in a qualification.  If a single issue is deemed by the auditor to be systemic or a group of issues lead the auditor to believe there is a failure of controls, then a qualification will be generated.  A qualification is not an indication of a bad organization; a qualification just indicates an area that requires improvement.  However, depending on the controls qualified, you may feel that your outsourcer has issues in meeting their PCI compliance obligations.

The final area that should be reviewed is a section labeled ‘User and User Auditor Considerations’.  Not all SAS 70 reports have such sections but those that do are typically invaluable to the user organization.  This section describes the controls that your organization needs to have in place and functioning in order for the outsourcer’s control environment to function as described in the SAS 70 report.  This is similar to the purpose of the Implementation Guide required in the PA-DSS.  Without this section, your organization would not know its responsibilities for creating complimentary controls so that the controls in place at the outsourcer remain functional and effective.

Entire books have been written on the SAS 70 process.  I hope that I have given you an eye into the process and how you can use it to reduce the amount of work to meet your PCI compliance.

UPDATE: It was announced in February 2010 that the SAS 70 standard will be superseded by SSAE 16 in the United States and by ISAE 3402 internationally.  From a user and user auditor standpoint, these new auditing standards do not change much from the SAS 70, so what is stated here still is valid.  See my new post entitled SAS 70 Is Dead for more information on SSAE 16 and ISAE 3402.