Controlling Vendor Access
                            By: Mitchell H. Levine, CISA
                                    Audit Serve, Inc.

Companies both large and small are faced with a common problem, controlling external vendor access that provides production support for third party vendor products they use.

No matter how large an organization is, all application software used to support business processes are not internally developed.  Establishing a control structure which accounts for all changes being made is the number one issue which needs to be addressed.  To determine whether an effective control structure can be established, a determination needs to be made as to degree in which the external vendor controls an organization’s production system.  

The first step is to determine the overall risk based on the roles and responsibility of the external vendor.  Is the vendor supporting a product also the developer of the product?  Many organizations are in a relationship in which the vendor has developed a product in which the organization uses exclusively or on a non exclusive arrangement.  This type of relationship in most cases translates to a “hands on” vendor access to the organization’s system.  The second question is whether vendor has database and system administration responsibilities to the production server.  If the database and system administration roles are not separate from the application production support responsibilities then this is a recipe for disaster and no controls could be put in place which adequately mitigates the risk of unauthorized changes.  A separation of duties should even exist between the system administrator and database administration.

Even if the external vendor is not the developer of the product used by an organization, many of the same control issues exist.  If a separation of duties can be established between the vendor who develops/releases the code and an organization that deploys the code to production, then a checkpoint can be established to identify the changes being made to ensure it relates to an enhancement request or a reported problem.  The other control concern relates to compilable code.  If the code is compilable, a proper control structure would have the organization perform the compile and not the external vendor.

The next step to establishing an adequate control structure is to ensure that production support is managed in a manner which ensures that all changes can be identified and tied to a specific production support problem.  The first control requirement is to determine the extent of the audit trails which are available to identify data, system level, and application program changes.  The most critical component of the three is direct changes to data.  From a fraud standpoint, this is easiest method to commit a fraud.  It is also the most legitimate reason for making production support changes.  The reason is simply that data corruption occurs within application which causes stored data values to be inaccurate.  In order to change the data, normal front-end interfaces are not available to change every piece of the data on the system which is the reason why data is directly altered through SQL code or other third party vendor tools. 

Unfortunately, few tools are available within the industry which provide and audit trail which can be presented in easily understood format.  In many cases, enabling the level of auditing required to identify all data changes could cause performance problems.  However, auditing specific support Ids which are used to make these changes should not present any unnecessary system performance overhead.  The most controlled method to handle direct changes to data is to force a one-time program to be written which is required to go through the formal change management process.

An additional control required to handle production support changes is to control the Ids which are used for support.  These production support Ids are privileged Ids. Depending on the frequency in which the vendor needs to perform production support, consideration should be made to only release these Ids until they are required which is tied to a specific problem.  The period of time in which the Ids are active should be limited to ensure that an ID is not used to support multiple problems which are not being tracked.  In summary, the release of each production support IDs should be tied to a specific production support incident.  If process is not established to release the production support ID then the checkpoint to tie its use to an incident will be lost.

In summary, controlling external vendor access needs an organization to understand the circumstances in which the vendor needs to access their production system. When possible, these functions should be handled by internal personnel.  Also, consideration should be made to provide inquiry-only access to external vendors and only provide privileged access until there is a production problem which needs to be addressed.  Finally, the vendor should be required to document all changes they made to the system.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.