Performing an Audit of a SaaS Deployed Application
(Part 1 of 2)
By: Mitchell H. Levine, CISA - Audit Serve, Inc.
It is important to understand the functional limitations of SaaS because this also provides a limitation of the controls which can be established. The basis for the audit approach discussed within this article was developed based on a Salesforce.com environment but the components contained within this article can be used within all types of SaaS environments. Salesforce.com was built based on the SaaS software delivery models.
Other companies such as SAP have recognized the success of the SaaS software delivery model and now plan in the future to offer their CRM application in this fashion.
Understanding the SaaS Components
SaaS applications are written for a specific business area (e.g., sales) or functional process (defect tracking) which provides the flexibility in terms of how the application can be configured in order to scale to the size of the business it will support. The customization capabilities in most cases involve the screen input fields which are defined and the processing rules regarding the data input requirements. Although the SaaS vendors provide built-in reporting capabilities, most organizations establish a replica database within their own processing environment which is used to establish an internal data warehouse to allow for additional reporting. Organizations are also building data interfaces directly from the data residing in the SaaS which allows organizations to pass data directly to their internal systems.
Assessing the Data Design
Organizations need to make a decision on whether their entire organization will be operating within a single database. The decision is based on the level of data integration which is expected within an organization. In the case of Salesforce.com, the generation of reports to track sales in the in Pipeline is based on having one database defined. However, just because one single database is used within an organization does not mean that an organization will have one single view all of its business units. This “single view” is predicated on the use of common fields throughout the organization. However, if business units within an organization do not coordinate the use of the same fields, then the ability to establish management level reports which provides a global view of the data across an organization will not be possible.
Conversely, organizations can fall into bad data design practices in which business units use the same field for different purposes which would provide inaccurate reporting at the management level.
Typical SaaS applications include vendor provided fields which relates to common use of its application within a specific industry. In many cases the built-in reports provided as part of the application directly relate to the vendor provided fields which requires an organization to use these fields in order to use the built-in reports. An organization should be aware of the importance of the vendor provides fields along with the implications if they are not used properly.
SaaS applications provide the ability for organizations to define custom fields for their own use. It is important that the use of these custom fields is documented from a system and user standpoint.
The second part of this article will focus on the other areas which should be included in an audit of a SaaS deployed application
Mitchell Levine is the founder of Audit Serve, Inc. Audit Serve performs
PCI Assessment and Remediation Project Management consulting services. Audit Serve also conducts Integrated & IT Audits, SOX Control Design & Testing and Penetration Testing. Email Mr. Levine at Levinemh@auditserve.com if you would like to discuss your organization's specific project requirements in order to establish a proposal of services.
Copyright 2008, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing
Join 3,500 other subscribers
Advertise with Us