The Schellman Blog

By Eric Sampson and Doug Barbin In a previous article, we provided a summary of the key components of the PCI DSS Cloud Computing Guidelines (“cloud supplement”). That article focused on roles, responsibilities, agreements, and audit considerations. This article speaks more to the technical considerations.

The writing is on the wall. For many businesses, cloud providers are becoming a key component of IT and business strategies, service delivery capability and scalability, innovation, and delivering new service models and solutions to market. For merchants and service providers that store, process, or transmit cardholder data, the PCI DSS provides the requirements necessary to ensure a secure and compliant cardholder data environment. Until recently, guidance was limited to the interpretation of existing PCI standards, which never fully accounted for today’s evolving cloud computing models. The release of the PCI DSS Cloud Computing Guidelines (“cloud supplement”), attempts to align core PCI goals with a better understanding of cloud provider and cloud customer (“tenant”) responsibilities to maintain a compliant cloud-hosted cardholder data. Schellman had the privilege of participating in this group. The document is, by default, supplementary and as with all PCI supplements does not supersede, replace, or extend the PCI DSS requirements. In fact, the cloud supplement states they are provided especially to “[present] recommendations for starting discussions about cloud services” in giving cloud providers and tenants a point of discussion for approaching their individual roles and responsibilities in meeting the PCI DSS requirements.” In the cloud supplement, the SSC describes the following important areas, to name a few, for understanding provider and client relationships:

DevOps, like Agile development before it, accents the continuous evolving state of software development, particularly in cloud-base software. Like any technology change, there is no surprise that auditor and security professionals are challenged as the traditional separation of duties become more and more gray. As someone who oversaw product management in an Agile / SaaS development environment and now manages audits and certifications for leading edge cloud solution providers, I offer my perspective.

I am delighted that Schellman is now an accredited FedRAMP 3rd Party Assessment Organization (3PAO). This is a testament to our extensive experience in the cloud service provider (CSP) space and the qualifications and experience of a licensed CPA firm, PCI QSA company, and ISO 27001 certification body.

If your organization is seeking ISO 27001 certification, and you outsource physical hosting to a third-party vendor, you may be wondering if and how to include them in the scope of your Information Security Management System (ISMS).

In October, I posted an article on the various alternatives for CPA attestation reports. This past week, the AICPA issued its guidance on Service Organization Controls (SOC) 2 reports and an update to that post was in order. Here is what the newly released SOC 2 guidance states:

All reports on controls at service organizations must be performed in accordance with SSAE 16 and/or ISAE 3402 by June 15, 2011. Because the new standards are heavily based on the existing SAS 70 audit standard, the examination process and resulting report will be very familiar to service organizations that previously completed a SAS 70 audit. However, there is one activity that is likely to be more time consuming than any other during the transition process, which is the conversion of the SAS 70 description of controls to an SSAE 16 “system description”. According to SSAE 16, management’s description of the service organization’s system should identify the services covered by the assessment, the period to which the description relates (or in the case of a type 1 report, the date to which the description relates), the control objectives specified by management or an outside party, the party specifying the control objectives (if not specified by management), and the related controls.The service auditor is required to opine, in part, as to whether management’s system description is “fairly presented”. Paragraph 14 of SSAE 16 provides service auditors with the minimum system description contents that should be present to conclude that a system description is fairly presented. In order to minimize the risk of a fairness of presentation opinion letter qualification, all service organizations should review the list below and verify that their SSAE 16 system description addresses each of the applicable requirements. The types of services provided to user entities, including, as appropriate, the types of transactions processed. The procedures, within both automated and manual systems, by which services are provided, including, as appropriate, procedures by which transactions are initiated, authorized, recorded, processed, corrected as necessary, and transferred to the reports and other information prepared for user entities. The related accounting records, whether electronic or manual, and supporting information involved in initiating, authorizing, recording, processing, and reporting transactions. The procedures for the correction of incorrect information. The method of transferring information, including, but not limited to, reports to user entities. The method that the service organization’s system captures and addresses significant events and conditions other than transactions. The process used to prepare reports and other information used for user entities. The specified control objectives and controls designed to achieve those objectives, including as applicable, complementary user entity controls contemplated in the design of the service organization’s controls. Other aspects of the service organization’s control environment, risk assessment process, information and communication systems (including related business processes), control activities, and monitoring controls that are relevant to the services provided. In the case of a type 2 report, relevant details of changes to the service organization’s system during the period covered by the description. It should be noted that SSAE 16 requires the service auditor to determine whether management’s description of the service organization’s system omits or distorts information relevant to the service organization’s system, but acknowledges that management’s description is prepared to meet the needs of a broad range of user entities and their user auditors. Therefore, system descriptions are not required to include every aspect of the service organization’s system that each individual user entity and its user auditor may consider important in its own particular environment. Rather, system descriptions should utilize a “lowest common denominator” approach that presents a level of detail about the system that will be equally applicable to all user entities. Using this approach will ensure that user entities do not misinterpret the applicability of the system description and related controls to the services to which they subscribe.

In 2001, an international effort began to “converge” the disparate accounting standards of the world in order to provide a framework that better meets the demands of globalization. The various national standard setting boards have spent years cooperatively developing a single set of international standards to which countries are encouraged to adopt. In the United States, the American Institute of Certified Public Accountants (AICPA) is actively revising and re-codifying many US accounting standards to better align with these new international standards.