IT Governance

Attest

OBJECTIVE —The cloud computing audit/assurance review procedures are designed to:

  • Provide stakeholders with an assessment of the effectiveness of the cloud computing service provider’s internal controls and security
  • Identify internal control deficiencies within the customer organization and its interface with the service provider
  • Provide audit stakeholders with an assessment of the quality of and their ability to rely upon the service provider’s attestations regarding internal controls

SCOPE — A review focuses on:

  • The governance affecting cloud computing
  • The contractual compliance between the service provider and customer
  • Control issues specific to cloud computing

Control

aBIZinaBox is actively involved in monitoring internal control systems and IT and it provides useful guidance and tools for enterprises interested in applying information technology to support and sustain the monitoring of internal control. There is much literature available which provides guidance for the design and operation of monitoring activities over existing IT controls. However, customization of the provided approaches reflecting the specific circumstances of each enterprise is required which is where aBIZinaBOX can help.

The main goals of our services in this area are to:

  • Complement and expand on the 2009 COSO Guidance on Monitoring of Internal Controls
  • Emphasize the monitoring of application and IT general controls
  • Discuss the use of automation (tools) for increased efficiency and effectiveness of monitoring processes
SOX Services

The growing popularity of Software-as-a-Service (SaaS) is having a significant impact on data security and regulations compliance. Most companies are concerned – and rightly so – about the legal and security issues raised when company data is located outside their firewall. This article will explain:

  • What you must include in your legal contracts to protect your company against Sarbanes-Oxley (SOX) compliance violations
  • What SAS 70 Audit Types I and II are, and how they help ensure that companies protect your data
  • How to guard yourself against the "1,000 social security numbers on a lost laptop" problem
SaaS is Here to Stay

Software-as-a-Service is increasingly popular, and for good reason. Its advantages include a greatly reduced time-to-deployment, low upfront costs (for less approval-process drag), and much less need for scarce IT staff involvement. The result is lower business risk by eliminating "bet-the-company" deployment steamrollers, unpredictable cost spikes, and upgrade or maintenance nightmares. For these and other reasons, major industry analysts predict that 25 percent of business software will be delivered under the SaaS model by 2011.

The upside to SaaS is tremendous. But the business rewards that SaaS brings are not completely without risk. As companies think about bad things that can happen to their data, they often consider these:

  • Phishing or social engineering targeting the SaaS vendor
  • Insufficient uptime and/or scalability of the solution
  • Unplanned maintenance outages
  • Theft of data by SaaS vendor employees
  • External system attacks.

SaaS is not necessarily more risky than implementing your own in-house solutions. In fact, it is often much less so when you account for opportunity costs, reduced business agility, and ongoing maintenance. Nevertheless, it is reckless to ignore or overlook a SaaS vendor's operational and business risk potential. So what can you do to ensure that your company can reap the rewards of SaaS while tightly managing the risks?

First, realistically and systematically assess the risks. What kind of company data will be contained in this particular SaaS system? Then, match the level of risk management to the level of data sensitivity or importance.

SaaS and SOX

Publicly-traded companies have a particular concern about SaaS – namely, its impact on Sarbanes-Oxley (SOX) regulatory requirements. The SOX act holds signing officers responsible for the fairness and completeness of their company's financial statements. They also are held responsible for the state of the company's internal controls, and must report any deficiencies. An internal control is a process designed to reasonably assure that objectives can be met in the following categories: financial reporting reliability, operational effectiveness and efficiency, and compliance with applicable laws and regulations.

If SaaS solution data touch the company's financial statements, the company is responsible for the controls on that software service. This is a daunting prospect for IT executives and staff, whose jobs are on the line where IT controls are concerned. Evaluating and assuring your own controls is one thing – but how can you be sure about your SaaS vendor's controls?

SAS 70 Audits

Asking your SaaS vendor for a copy of their SAS 70 Audit Report is a good place to start alleviating concerns. SAS 70 stands for Statement on Accounting Standards (number) 70, professional guidance issued by the American Institute of Certified Public Accountants (AICPA). The SAS 70 Audit Report documents and attests to the adequacy and completeness of the SaaS vendor's internal controls for their service. If your company is subject to SOX requirements, you should require all your SaaS vendors to provide a SAS 70 Audit Report.

This report is designed to be included in your own audits of controls. Because it is an "auditor-to-auditor" report, it can obviate your own physical audit of the SaaS vendor, saving you time and money.

Even if you are not subject to SOX, you may still find the SAS 70 audit report valuable, since it details exactly what your SaaS vendor is doing to protect your company data. There are two types of audits, (logically) named SAS 70 Type I and SAS 70 Type II. The Type I audit assesses whether the SaaS vendor's internal controls are fairly and completely described, and whether they have been adequately designed to meet their objectives. The Type II audit does the same, but also goes a step further to test the controls in operation.

The Type II is more rigorous and usually preferred; however, many companies begin first with a Type I audit and follow on with a subsequent Type II audit. The additional assurance of a Type II is good to have if you need it; indeed, your own auditors may insist on it. Understand, however, that SAS 70 audits are somewhat new in the SaaS vendor world. Many vendors are starting off with a Type I, and following it with a subsequent Type II. Ask yourself: exactly how sensitive is the data in this SaaS system? Do we have the ability to configure the system to control and approve the data it contains? Is the vendor demonstrably on schedule toward the type of audit we need? The answers will help you decide which type of audit report (I or II) you will absolutely need today and later on.