Cloud computing, outsourcing, and their accompanying risks demand that we move beyond the vendor checkbox that SAS 70 represented.
We're in the midst of an IT and business process outsourcing boom. The innovation and economics of cloud computing, coupled with recessionary pressures, make software, infrastructure, platform, transaction processing, claims processing, payroll, and other services more attractive. For established businesses, some form of outsourcing is central to reducing costs and improving functionality, while just about every new or emerging business is looking to outsourcing to build out its IT infrastructure.
With this wave comes not only an incredible array of services and complexities, but also considerable risks, which vary depending on how services are being used, what data is being exchanged, how data is being manipulated, and which business functions depend on the continuity of IT infrastructure. And as we see in the headlines every day, the security threat is very real.
So businesses must be stepping back and doing a fresh assessment of those service providers and deploying appropriate governance approaches, right? You'd think so--but they're not.
SAS 70 reporting, released by the American Institute of Certified Public Accountants (AICPA) in 1992, set up a process for a vendor to be audited once, and for that report to then go to its various customers so that each one wouldn't have to conduct its own audit to ascertain the integrity of the vendor's impact on the customer's financial statement reporting.
While SAS 70 was and always has been about auditing of financial statements, misperceptions and various actors have co-opted the report over the years to position it as something it's not. SAS 70 is not a basis for assuring that a vendor has managed and is controlling risks for anything other than its customers' internal control over financial reporting. Many people reading that sentence are probably taken aback, because most people think that once they either issue or have in hand a SAS 70 report, all risks are covered.
With the emergence of software as a service and other types of cloud computing, vendors have consistently integrated terms such as "SAS 70 compliant" and "SAS 70 certified" into their sales and marketing language, suggesting that the mere existence of a SAS 70 report means the vendor is on top of security, privacy, operations, and other matters independent of their impact on financial reporting. But SAS 70 reports suggest no such thing.
Recently, Epsilon and Amazon Web Services had widely publicized incidents that are examples of the types of risks with today's cloud-dominated business models, as well as examples of the false sense of assurance vendors' SAS 70 reports can provide. Epsilon and AWS had cited their SAS 70 reporting as evidence that their customers could trust their risk management over the very areas that were subsequently exposed.
SAS 70 didn't, doesn't, and never will provide assurances for functions such as security and privacy (Epsilon) and security and operational performance (AWS). The only potential consideration is that security is included in SAS 70 as it pertains to supporting infrastructure relevant for financial reporting governance.
To be sure, SAS 70 has filled a critical role in the financial audit process, but most SAS 70 reports in recent years have been produced to create assurances in areas outside SAS 70's purview. In my experience, between 50% and 75% of SAS 70 reports have been prepared for scenarios where they weren't appropriate, putting customers that relied on those reports at great risk.
On June 15, the SAS 70 report officially was superseded by Statement on Standards for Attestation Engagements No. 16 (SSAE 16). Meantime, the AICPA announced a broader Service Organization Control (SOC) framework, which offers vendors other options to provide their customers with risk-management assurance. However, many Fortune 500 companies cling to the past, routinely requesting that their vendors prepare SAS 70 reports.
Moving to more effective risk management means moving past a culture where vendors and customers go through the motions of producing reports that nobody reads and everyone cites as evidence of proper risk management. This new culture is characterized by the vendor and customer having a clear understanding of the nature of the services to be rendered; how those services will be delivered, including the information systems and key data processes; and the roles of the personnel and organizations providing the service. With this understanding, vendors and customers can identify and agree on inherent risks and best approaches to mitigate and manage those risks. Ultimately, isn't that what stakeholders expect?
The SAS 70 era was focused on the checkmark--get the report just to say you have it. As of June 15, the page turned and the focus is on facilitating ongoing monitoring by the customer. Vendors will now report to customers based on predetermined schedules and provide high levels of transparency and control testing, customized to meet specific risk management needs.
This new approach, called Service Organization Governance, is much more effective because it's integrated into the customer's overall risk management framework. It's not something that's standalone or ad hoc.
Given the roles cloud computing and outsourcing has assumed in our economy and the enormous risks they represent, it's time to take risk mitigation seriously and transcend the checkmark.
Dan Schroeder, CPA/CITP, CIA, CISA, CISM, is a partner at Habif, Arogeti, & Wynne LLP in Atlanta and the chair of the AICPA's information technology executive committee.
InformationWeek Analytics is conducting a survey to see if companies are on the road to services-oriented IT and to highlight the challenges to this transformation. Respond to the survey and be eligible to win an iPod Touch. Take the survey now. Survey ends July 8.
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.