Home » Data Protection » PCI and Compliance

In Depth

SAS 70

SAS 70, the auditing standard, is finding its way onto CSOs' desks.

By Michael Fitzgerald

November 01, 2005 — CSO — The SAS 70 audit—an increasingly popular examination of internal corporate controls—is the source of confusion and debate in the information security world.

There are those who swear by it. Jennifer Bayuk, managing director of IT security at Bear, Stearns & Co., calls a SAS 70 audit "probably the best you can get for a security test, especially when you compare it to something like a security penetration study."

Then there are those who swear about it. Jonathan G. Gossels, president of consultancy SystemExperts, wrote in a paper that "SAS 70 is neither a meaningful security metric nor worth the high cost of obtaining the SAS opinion."

They're both right—and that's not a dodge. SAS 70 (full name: Statement on Auditing Standards No. 70, Service Organizations) can indeed be very helpful in examining the quality of a potential business partner's information security controls. But SAS 70 can also be very damaging when it is misrepresented as simple proof of ironclad security, which some experts say is an unfortunately common occurrence. This article equips CSOs with an understanding of how to be helped, not hindered, by the rise of SAS 70.

Control Issues

Understanding SAS 70 starts with understanding internal controls. Such controls, in the financial context, might include, for example, a clear segregation of duties so that Fred in accounting can't authorize himself to buy a Hummer.

The Sarbanes-Oxley Act is essentially a mandate to establish internal controls so that corporate executives can't fudge their numbers. Sarbox requires that companies verify the accuracy of their financial statements, and establishes SAS 70 Type 2 audits as a way to verify that third-party providers meet those needs. (SAS 70 Type 1 audits are not relevant to this article.) If a company outsources some transaction processing or data hosting that in any way affects its financial reporting, the company has to verify that its outsourcing providers' controls are also up to snuff. SAS 70 can examine controls such as the processes for assessing risk, managing third-party vendors and ensuring systems security. In her book Stepping Through the IS Audit, Bayuk includes a sample audit with a dozen ways to help verify the controls for systems security, including aspects like access controls, ways to report security breaches, and even big-ticket items like how to ensure IT security is aligned with business requirements.

So far, so simple. But there is a key nuance that CSOs must understand. A SAS 70 audit does not rate a company's security controls against a particular set of defined best practices. In a SAS 70 audit, the service organization being audited must first prepare a written description of its goals and objectives. The auditor then examines the service organization's description and says whether the auditor believes those goals are fairly stated, whether the controls are suitably designed to achieve the control objectives that the organization has stated for itself, whether the controls have been placed in operations (as opposed to existing only on paper), and in a Type 2 engagement, whether these controls are operating effectively. The fact that a company has conducted a SAS 70 audit does not necessarily mean its systems are secure. In fact, a SAS 70 may confirm that a particular system is not secure, by design.