SAS 70

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.”

UPDATE: See details of SAS 70’s 2011 upgrade to SSAE 16

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.

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.

(See Bayuk’s article Information Systems Audit: The Basics.)

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.

“You can have control objectives to make any statement management may want to make,” says Robert Aanerud, chief risk officer and principal consultant at security consultancy HotSkills. In effect, he says, management could decide that the company is OK with bad access control, and the auditor (who must be a CPA) then needs to ensure that access control is at least bad. The SAS 70 opinion would essentially say that, yes, the company has achieved its stated control objectives.

SAS 70 Don’ts, and Dos

Defining security-related objectives is not simple, and wading through SAS 70 audits to see where they do and don’t cover what your firm needs to know takes substantial amounts of time. Because SAS 70 was meant to look at financial controls, a SAS 70 audit report may have plenty that has nothing to do with IT security. What CSOs care about may be buried somewhere on a page or two in the middle of a SAS 70 report, which can run hundreds of pages. And CSOs must further read a SAS 70 in context of how their company would establish controls and compare those to how the potential service provider does.

Unfortunately, consultants say many companies are skipping the hard work and treating SAS 70 as a security rubber stamp. Sharon O’Bryan, head of O’Bryan Advisory Services, says she’s aware of companies taking SAS 70 reports for potential service providers, sticking them someplace and never reading them.

That’s a failure of due diligence, and O’Bryan is working with at least one company that has suffered the consequences. The company hired a service provider without looking in detail at the vendor’s SAS 70. Later, a customer called wanting to know about an account breach. Eventually the financial services firm traced the breach to systems at its outsourcer. Needless to say, it turns out that the outsourcer had significant issues with its information security practices, including people without the right qualifications or experience handling key information security positions. The outsourcer essentially wasn’t capable of protecting a key database, which was where the breach ultimately occurred.

All of this information was contained in the SAS 70 write-up. O’Bryan says the report included the relevant information on the outsourcing provider’s control objectives, and that the outsourcer did not have in place what it needed to meet those objectives.

But the company did not read the report.

The incident also shows, however, that properly used, SAS 70 would have worked as a security buffer. Bear Stearns’ Bayuk says that in fact, SAS 70 audits generally are very revealing. She notes that “often a SAS 70 will include negative results. It’s pretty comical…right on Page 46 it’ll say, We tested this control and it failed.'”

Shamla Naidoo, CISO at Northern Trust, agrees that while SAS 70s can’t be treated as gospel, they nevertheless offer plenty of useful information. “SAS 70s should not be used to replace due diligence on a vendor’s information security practices,” says Naidoo, who came to Northern Trust in early 2005 after four years at ABN Amro. She says SAS 70 reports are best used primarily as a jumping-off point for validating security controls. “We need to use it for what it was designed for. It attests to adequate controls, not information security. Information security controls are much more granular, and you need to go deeper [than SAS 70],” she says.

Companies, then, must also expect to invest a certain amount of time in reviewing SAS 70s—Naidoo says she’s seen 300-page SAS 70 write-ups, which makes for a challenging review. But even slogging through a big SAS 70 audit requires less time for Northern Trust than going out and doing its own security review from scratch on a potential provider. The main challenge with a SAS 70 is that there is no standard way of defining controls.

Mostly, that’s by design—audits aren’t supposed to force companies into cookie-cutter approaches. “Each organization defines control objectives uniquely,” says Naidoo. “In some cases you may have to look at three objectives to make sure [a SAS 70] covers the areas you’re concerned with. In others, it might be 15.” Naidoo recommends that her teams first know what level of controls—such as access, authentication and intrusion detection—they would need in order to verify security for processes, and use that as a framework for comparison with a potential service provider’s SAS 70.

In effect, Naidoo creates an internal map of how controls should work, something Bayuk also does at Bear Stearns. Bayuk pays special attention to the first page of a SAS 70 audit, where the auditor gives a summary of the process being audited. “Often you’ll see that it doesn’t cover the application you’re processing, or the infrastructure, or vice versa,” she says.

She also says SAS 70 is useful for controls because while it isn’t standardized, it follows a set of well-established procedures and tests to see if a company has followed its own controls. “I would never use an ISO 17799—you can have the best process to assess risk and identify vulnerability and have it on your queue to implement and never implement it,” she says.

SAS70 On the Rise

Service providers say they’re being asked more and more often for SAS 70 audits, often instead of governance standards like Cobit or ISO 17799. That’s even true for companies that handle security functions, traditionally more oriented toward granular best-practice tests than the broad audit test of SAS 70. Michael Scher, general counsel and compliance architect at Nexum, a security product and service provider, says his company is preparing to undergo its first SAS 70 audit. “It’s an efficiency-type move,” Scher says. It will save his company the trouble of having to be audited by every potential client, or generate reams of documentation in answer to questions. Scher knows that SAS 70 objectives can be loosely writtensomething that does fine in an audit “could definitely have some big gaps in the real world,” he notes. But he says the same is true for ISO 17799. In fact, he asks, rhetorically, “Is there any regime that’s oh so wonderful?”

“All these things are slippery,” agrees Richard E. Mackey Jr., a principal at SystemExperts. SystemExperts is the home of Gossels, the consultant who excoriates SAS 70 as ineffective makework for CPAs. But his colleague Mackey says SAS 70 is the de facto standard for checking out security. “If you have policies you want to maintain, the SAS 70 will check that you in fact met those policies and are compliant with them,” he says.

There are issues with how to structure objective controls that are meaningful, and how to look for things that perhaps were left out of the control statement entirely, such as whether systems with passwords in fact have controls on who can access them, and what policies guide who can or cannot have access.

The bottom line with SAS 70, then, is this: There are no silver bullets for corporate IT security. SAS 70 is another weapon in the arsenal—one to wield with due care.