Is there a SOC certification similar to an ISO 27001 certification?

Is your organization ready for a SOC 2 examination? Here are five steps to help successfully prepare for one: 1. Validate the nature of the request. Does your client base understand the various SOC reporting options and what they are asking of your organization from a compliance reporting perspective? Is there a connection to internal controls over financial reporting (ICFR) of the services that you provide to your clients, or are you looking at general controls of a system that are relevant to security, availability processing integrity, confidentiality, and privacy? SOC 1 can oftentimes be misused by the general public as a generic reference to third party audits. There is misconception in the marketplace; help prevent it.

Periodic reviews of system access are critical for service organizations who wish to maintain strong internal control around information security. Access privileges to systems or physical locations that impact the customer’s business environment should be commensurate with the requirements of the services provided. These privileges should also facilitate segregation of incompatible duties. For example, in order to segregate incompatible duties, a system developer generally should not also have access to migrate changes to the production environment.

When auditors begin to test procedures for compliance examinations (i.e., SOC 1, SOC 2), there are cases where the clients are performing certain tasks; however, they are not documented, which puts the auditors in a precarious position.

In my line of work, it is not only advisable to have a mastery of the facts, but prudence would suggest that a good dose of foresight and reason based on actual experience can often times be as valuable a tool. Since the days of the SAS 70, we have seen several subjective opinions about both the appropriateness and/or the ineffectiveness of the SAS 70 report. Even today, there continues to be concerns on how SOC 1 reports, also known as SSAE 16 examinations, are being used in situations that fail to have bearing on internal controls over financial reporting.

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.

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.