In Depth

SAS 70

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

By Michael Fitzgerald

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

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.'"

• Email
• Print
• Comments
• Digg This
• SlashDot