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.
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.
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.
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.
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.
Bear Stearns’ Bayuk says that in fact, SAS 70 audits generally are very revealing. “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. 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.
The main challenge with a SAS 70 is that there is no standard way of defining 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.
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. “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.
http://www.csoonline.com/read/110105/sas70.html