Find Your Industry

SAS 70 Audits and PCI DSS | Technical White Paper

SAS 70 Type II audits and PCI DSS Level 1 assessments have quickly become two of the most widely recognized regulatory compliance mandates facing organizations in today’s business technology and outsourcing environment. SAS 70, an auditing standard put forth by the Auditing Standards Board (ASB) under the authority of the American Institute of Certified Public Accountants (AICPA) in 1992, has gained widespread use and popularity in recent years. Similarly, Payment Card Industry Data Security Standards (PCI DSS) compliance has taken root, affecting a large number of merchants and service providers in the United States and across the globe. At first glance to the untrained eye, one could quickly assume that both SAS 70 Type II audits and PCI DSS Level 1 assessments share many similarities, so much so that audit efficiencies can be had by combining or leveraging many of their respective requirements. To be fair, organizations seeking to be both SAS 70 Type II and PCI DSS Level 1 compliant are looking for cost-effective measures in meeting today’s ever-growing compliance requirements. A trend of late that many organizations are witnessing is the potential leveraging of fieldwork activities and other associated audit documentation for the purposes of issuing both a SAS 70 Type II audit and a PCI DSS Level 1 Report on Compliance (ROC) assessment.

Thus, the subsequent discussion herein constitutes a discussion of both compliance initiatives for determining what efficiencies of scale can be had, if any, along with highlighting other notable topics deemed critical for analysis.

Brief History

Statement on Auditing Standards No. 70 (SAS 70) is part of the AU Section 324 Codification of Auditing Standards which is used to report on controls placed in operation and the testing of the operating effectiveness of those controls. Its primary application can be found in the inquiry, examination, and testing of a service organization’s control environment. Technically speaking, a “service organization” is the entity that is providing services to a user organization, with these services being part of the user organization's "Information System." In simpler terms, “service organizations” are the ever-growing list of companies that are providing critical or material (or “relevant”) third-party outsourcing services to the “user organization” entities. Common examples of service organizations in today’s regulatory compliance environment are data centers, managed-service providers, Software as a Service (SaaS) vendors, medical claims processors, and third-party administrators (TPA), just to name a few. In short, the SAS 70 auditing standard has illustrated a high level of effectiveness in examining the internal control framework of service organizations, and as such, will more than likely continue to be the primary audit tool for this application.

Payment Card Industry Data Security Standards (PCI DSS) is a multi-faceted security initiative put forth and endorsed by the major payment brands (American Express, VISA, MasterCard, Discover Card, and JCB) that includes requirements for protection of cardholder data by merchants, service-providers, and other third-party processors. The PCI DSS platform is managed and directed by the Payment Card Industry Security Standards Council (PCI SSC) in Wakefield, MA. Being PCI compliant can and does carry a host of different meanings and requirements, as there are varying levels of compliance for merchants and service-providers. For purposes of this discussion, our intent is to examine PCI DSS Level 1 and its applicability, if any, to that of SAS 70 Type II audits.

Audit vs. Assessment

In examining the relationship between these two compliance initiatives, it is important to understand their respective frameworks, intent, and what is required for compliance with each respective initiative.

Regarding the SAS 70 audit framework, it’s essential to note that within this AICPA auditing standard itself is a broad spectrum of flexibility and application to many aspects of the overall audit process, such as the following:

• There are no pre-defined control objectives that must be strictly followed. In essence, the entity undergoing a SAS 70 audit is free to develop controls objectives that will be subsequently tested for compliance. Generally, the scope of the audit and the subject control objectives should cover those control objectives and controls that are relevant to the foreseen user organizations.

• As of late, a myriad of frameworks are being represented and utilized in the SAS 70 audit process, ranging from COBIT and COSO to ISO, FFIEC, and other more conspicuous or non-traditional standards. Moreover, the Federal, State, and non-government organizations are beginning to request SAS 70 audits that include statutory and contractual frameworks to measure compliance with service organization relationships. Many other agreed-upon procedures can be incorporated as a condition by a user organization. The service organization is responsible for understanding the application of user organization standards.

• Other than the general AICPA SAS 70 standard itself, there is no formalized enforcement or standards body requiring SAS 70 audits to conform or comply with a clear and defined control environment architecture. Rather, conformity, if any, is being driven from an informal process which initially begins with the external auditors relying on SAS 70 audit reports of their respective user organizations. Their recommendations for audit scope and other essential requirement are pushed down to the service organization’s management.

• Many SAS 70 auditing firms have adopted their own, “best-of-breed,” predefined framework and control objectives, allowing for service organizations to readily adopt these measures for the overall audit process.

• Testing for controls in the SAS 70 audit process is highly subjective as auditors employ different methods for assessing population size, sampling, along with what constitutes a “relevant exception” for the audit.

• The final representation of a SAS 70 Service Auditor’s Report further illustrates the auditing standards flexibility as these reports are written and presented in a wide variety of formats and layouts.

In contrast, the PCI DSS framework for Level 1 compliance is a strict adoption of twelve (12) core requirements that have been comprehensively agreed upon by the major payment brands as a credible and sufficient assessment tool for cardholder data security compliance. What’s more, the twelve requirements give specific instructions and mandates when conducting assessments for Level 1 PCI DSS. In short, if the requirement is not initially met or cannot be met by implementing compensating controls, an official Report on Compliance (ROC) will not be issued.

The twelve requirements for PCI DSS compliance (enumerated guidelines) encompass many areas revolving around technology and security, particularly that of the protection of cardholder data. As such, an in-depth review of an entities “system components” forms an extensive and ubiquitous area of the assessment process. These “system components” are technically defined by PCI DSS as “Any network component, server, or application included in or connected to the cardholder data environment. Generally speaking, this will include all network components, operating systems, applications, databases, data transmission protocols, along with numerous other technology devices and daily operational procedures.

In summary, it’s a comprehensive and far-reaching compliance initiative that may potentially surpass the scope of a SAS 70 audit for purposes of Information Technology and security related controls. But then again, one must remember that a SAS 70 audit is not per se a technology audit nor is it exclusively a security audit.

Rather, SAS 70 audits examine and test an organization’s internal control framework and overall control environment of the service organization’s business process(es), of which the SAS 70 audit scope may often encompass both technology and security as part of the audit scope. In fact, the amended SAS 70 auditing standard includes provisions from SAS 78, a subsequent auditing standard, which provides guidance to auditors concerning the effect of information technology on internal controls. Even with that said, the specifically enumerated guidelines of the PCI DSS requirements for technology and security controls, as stated earlier, are often much more specific technically than the general controls covered in a SAS 70.

Thus, organizations seeking both compliance initiatives and, likewise, auditors who conduct both PCI DSS assessments and SAS 70 audits have started to “curiously” develop auditing methodologies that encompass both of these compliance initiatives. This has evolved to such a degree that one may sometimes hear the phrase “2 for 1”. That is, auditors are first conducting a PCI DSS Level 1 Report on Compliance and then using the audit fieldwork deliverables and supporting documents to suffice for many aspects of a SAS 70 Type II audit. The primary reason for conducting the PCI DSS assessment first is rather obvious; it is a specifically technical guideline oriented assessment that could potentially encompass many “control objectives” and supporting “tests of controls” directly relating to Information Technology and other areas for a SAS 70 Type II audit.

However, this type of auditing methodology, though geared towards efficiencies and cost-savings for clients, is inherently weak and perilous for the following reasons:

Test Period vs. a Sample of System Components

SAS 70 Type II audits consist of a test period, generally ranging from 6 to 12 months, thus audit evidence needs to be collected throughout the entire test period. In short, this implies recurring inquiry, observation, examination, and testing of controls throughout the audit test period. A PCI DSS assessment, though more often than not very technical in comparison to a SAS 70 Type II, speaks often of “a sample of system components” but gives no guidance or explicit requirements on what the coverage period need encompass. Thus, a large amount of documentation collection for a PCI DSS assessment can arguably be done as a one-time, point-in-time activity. Currently, this seems to be the trend with PCI DSS assessors, and as such, this type of audit evidence would arguably be incomplete for effective testing of controls for a SAS 70 Type II audit.

Business Process Controls

Many SAS 70 Type II audit reports include a large number of tests for business process controls specific to the industry in which or with which the service organization functions. Entities such as Third Party Administrators, Data Centers, and Software as a Service (SaaS) providers, just to name a few, often have many of their specific business processes or functions tested within a SAS 70 audit. Conversely, a PCI DSS assessment has essentially no scope or oversight on these specific business processes in regards to compliance, thus no testing of system components. Thus, a weakness in the PCI DSS standards may be the lack of flexibility to judge for the breadth of inquiry outside the enumerated guidelines with respect to the business process(es).

Service Auditor’s Report vs. a Report on Compliance

And the final deliverable for each of these compliance heavyweights is quite different also. Most SAS 70 Type II audits contain a lengthy narrative description of the controls throughout the Service Auditor’s Report, accompanied by a three column test matrix that is quite lengthy also. The Report on Compliance, (simply known as the ROC [pronounced “rock”]), consists of a brief narrative statement regarding the merchant or service-provider, additional discussions on the cardholder environment and then progresses into a lengthy excel styled grid, which comes pre-populated with the 12 PCI DSS requirements (the enumerated guidelines) and all the respective tests thereof. In short, there are few similarities when comparing the final deliverables of a SAS 70 Service Auditor’s Report to a PCI DSS ROC, so expect more than a redundant use of the auditor efforts to be had if conducting both of these compliance initiatives for one client.

In conclusion, the differences seen between SAS 70 Type II audits and PCI DSS assessments are quite evident, but some audit efficiencies may be had, but only on a degree substantiated by the scope needed to cover the SAS70 that overlaps the PCI DSS requirements. The efficiencies may be that both a SAS 70 audit (indirectly) and a PCI DSS assessment (directly) are intended to cover technology controls. Further, a fair number of I.T. systems and supporting drivers, such as policies and procedures, along with interviewing I.T. personnel, are examined and undertaken for both a SAS 70 and PCI DSS. However, taken in the aggregate, the differences are largely apparent, requiring SAS 70 auditors and PCI DSS assessors alike to think objectively, independently and undertake audit and assessment fieldwork activities that truly represent the intent, rigor and true spirit of each compliance requirement.

About NDB, Accountants and Consultants and NDB Advisory

NDB, Accountants and Consultants, a PCAOB registered certified Certified Public Accounting firm (www.sas70.us.com), and NDB Advisory (www.pciassessment.org), were founded in part by former Arthur Andersen and BDO Siedman auditors specializing in SAS 70 audits, I.T. audits, PCI DSS Assessments, and other regulatory compliance assurance needs for organizations in select markets. Our personnel have years of experience in our select chosen fields of work, possessing a sound working knowledge, interpretation and solid understanding of all relevant regulatory compliance issues and mandates currently affecting our clients.

Additionally, to learn more about SAS 70 Audits and PCI DSS Assessments, visit The Official SAS 70 Resource Guide and The Official PCI DSS Assessment Resource Guide.