Introduction

Compliance is essential to maintaining confidence in corporate integrity in the marketplace and the Sarbanes-Oxley (SOX) act has become the number one regulation driving compliance for public corporations since 2002.

The Sarbanes-Oxley Act requires organizations to select and implement a suitable internal control framework. Section 404 of SOX stipulates that management must demonstrate control over financial reporting. For Information Technology (IT), control activities must also be considered for the management and auditing of changes to existing and new software.

What control objectives or activities will be addressed?

Control activities are the policies and procedures that ensure business objectives are achieved and risk strategies are implemented. The Public Company Accounting Oversight Board (PCAOB) and the IT Governance Institute (ITGI) have developed standard frameworks for good IT security and control practices for management, users, and IS audit practitioners, for example, the Control Objectives for Information and related technology (COBIT). This paper will address the following subset of those control objectives:

• Manage Change - The organization’s controls provide reasonable assurance that system changes of financial reporting significance are authorized and appropriately tested before being moved to production.
• Acquire or Develop Application Software - The organization’s software development lifecycle policies and procedures consider the development and acquisition of new systems and major changes to existing systems.

The application development and maintenance controls are based on methodology and include: system design, system implementation, and change management. This paper will concentrate on these objectives and how to use IBM Rational’s tools for compliance; however, it will not address all of the control processes required by Sarbanes-Oxley.

What about the process?

The implementation of any tool requires the institution of control procedures or processes. Using IBM Rational’s ClearCase and ClearQuest to assist in SOX compliance is a great start; however, their process control and automation is dependent on the process your organization already has in place or will develop.

Compliance implementation overview

Implementing a clearly defined process using ClearCase and ClearQuest will assist you in achieving SOX compliance. The activities required for Sarbanes-Oxley should not be regarded solely for the purpose of compliance, but rather as an opportunity to establish a process model designed to ensure you meet your business requirements.

Using ClearQuest for change control in SOX compliance

IBM’s Rational ClearQuest is more than a defect and change tracking system. When implemented correctly, ClearQuest can become your compliance management tool for maintaining SOX compliance.

The "Managing change" control objective addresses how your organization modifies systems to help the business meet its financial reporting objectives. A deficiency in this area could significantly impact financial reporting and is therefore an important consideration for SOX compliance.

This section will explore several processes with ClearQuest for implementation of a complete change management system that helps meet SOX compliance standards.

Key elements in change management compliance

When looking at the control objective for Change Management, some key areas stand out for adapting your process to meet the requirements:

• All changes must be approved by management
• All changes introduced into the environment will be documented from the approval of the change to where it was implemented
• Sufficient metadata within a change request will be captured that assists in determining impact analysis
• Changes will be managed from inception to implementation (start to end)

SOX compliance and the ClearQuest workflow

When looking at addressing SOX compliance issues, we can start by incorporating compliance into the ClearQuest workflow. This gives us the ability to ensure that the proper reports are available during a SOX audit.

The key areas that need to be addressed in the ClearQuest schema are the ability to review and approve changes to an existing system and then the ability to track code changes to the system in a build for deployment into the production environment. This also includes the ability to verify that testing was conducted and the results are maintained.

If we take a default workflow to address this, it would look like that shown in Figure 1.

The key to implementing a simple workflow like this is that the process control in place to ensure that changes are SOX compliant. Group level security should be implemented that addresses who is authorized to approve changes to the system, and specific fields should be required throughout the workflow to ensure that required data are collected.

ClearQuest process control for defects and enhancements

To explain how this workflow functions, we can include specific data that indicates control over the workflow and that is in line with Sarbanes-Oxley requirements. Normally, you would create a separate document that details the actions that happen between states, however, in this paper we will simply indicate the actions by attaching notes to the relevant states.

As you can see in Figure 2, the key area that SOX is concerned with is the approval of any changes to the system. You can meet this objective, regardless of the state matrix you implement, by introducing an action that requires approval from the Change Control Board (CCB). Keep in mind that you must also show that the request has been tested and where the change was implemented.

Key fields to consider for SOX compliance

There are several key fields that can be implemented in a standard schema that will ensure the appropriate information is available during a SOX compliance audit.

1. Server environment: As shown in Figure 3, this field can be useful in identifying where the defect or enhancement originated. By identifying the origin of the request, you have proven that process controls begin at the capture of the request.
   
   Figure 3. Server environment specifed in a standard schema
   
   
   
2. Impact analysis field (Requirements/Impact tab): Part of the SOX compliance model is the ability to assess impacts to the production environment. By including an impact assessment on the request, you can use the Change Review Board minutes to discuss potential impacts to other applications and the environment, as shown in Figure 4.
   
   Figure 4. Impact analysis
   
   
   
3. Planned release field (Figure 5): This field is used to capture what release the request will be implemented in. This is an important field because this is where the SOX auditors will look to understand what changes were implemented for a particular release.
   
   Figure 5. Release field
   
   
   

4. Deployed in Build field (Figure 6): This field is one of the most important fields for SOX compliance. When looking at SOX compliance, we need to show where the change was implemented. As shown in Figure 6, in this instance, we are using the actual UCM baseline information to indicate the build number.

ClearQuest and the Unified Change Management implementation

Managing changes to an existing system, whether they are defects or enhancements, involves more than simply indicating a change was approved to be implemented into the production environment; you must also indicate what code changes were done to implement the change. IBM Rational’s UCM process fulfills this requirement by attaching the actual code changes to the request. With this implementation, you can show all changes to the code that have been approved for a specific release.

1. Approved changes and UCM: As shown in Figure 7, as long as you implement an approval process prior to assigning the request for development, the owner will only see approved requests for them to checkout code against.
   
   Figure 7. View of approved activities in ClearCase Explorer
   
   
   With UCM, when a developer wants to modify code they must associate it to a Change Set, as shown in Figure 8.
   
   Figure 8. Associating a change set to an activity
   
   
   
2. Building software and baselines: When a build of the software is conducted, a baseline should always be created that indicate the changes that were incorporated in that baseline, as shown in Figure 9.
   
   Figure 9. Make Baseline dialog box
   
   
   

Figure 10 shows activities in a baseline correspond to records in ClearQuest. Information about baselines and releases will be covered in the next section.

ClearCase code migration and management

ClearCase has a built in process that provides a perfect haven for SOX compliance; Unified Change Management. Implementation of ClearCase UCM allows you to control how code changes are made and implemented into different environments, including production. ClearCase has an audit tool capable of tracing changes to the source code back to an individual and the requirements for the change. With a little adjustment, SOX compliance in this area can be achieved in a very short amount of time.

Adjusting the Unified Change Management implementation

This article will not detail the steps needed to implement Rational’s UCM. However, we will focus on the areas that are needed for SOX compliance.

The ability to show SOX compliance in ClearCase is somewhat difficult because UCM has a default record type of BaseCMActivity. This is a record type that is used by most developers to associate a set of changes that span across levels of control. For instance, an enhancement request comes into the system for the login to have the ability to remember the user name. Once this request is approved by the CCB, it is determined that several people need to make modifications to the code in order to implement the change. Because there is only one record, it is assigned to a specific individual that will control the change; all others would create a BaseCMActivity to link changes with. The difficult part comes from the ability to show the changes made in a BaseCMActivity to the actual change request approved.

Using a parent-child relationship for BaseCMActivities

One solution that could be adopted fairly easily is to create a parent-child relationship from BaseCMActivities to a defect or enhancement as shown in Figure 11. Once implemented, you will be able to show all related activities for a specific request.

In this scenario, it is mandatory for the developer to select the parent ticket (defect or enhancement) that the BaseCMActivity is related to. Now, when we look at a request for SOX compliance, we can see any additional child activities that were created to support the request (Figure 12).

Note: While this is a very easy way to maintain SOX compliance, you must have a clearly defined process that accounts for all scenarios that may occur during the development lifecycle. For instance, if a developer finds a defect in the code that was already delivered and the parent record is already closed, he would normally create another BaseCMActivity to correct the mistake and deliver it immediately. Without an open parent activity, he would not be able to create the BaseCMActivity.

Without using a parent-child relationship for BaseCMActivities

You can implement the same controls without using a parent-child relationship by utilizing process controls to achieve the same thing. As shown in Figures 13, 14 and 15 below, by expanding the BaseCMActivity ticket type to include the base controls for SOX compliance as mentioned in the previous section, you can essentially treat the BaseCMActivity as a defect or enhancement.

Code migration controls for SOX compliance

Another area that companies need to be concerned with when trying to become SOX compliant is in the area of code migration (how code gets promoted into the environment). As a standard practice, you can use ClearQuest to control the movement of source code (builds) into your different environments. By providing controls on the movement of source code into production, you are addressing the SOX compliance issue which states that you need controls in place that sufficiently monitor changes introduced into production. And because we are using ClearQuest to manage deployments, you can introduce security and approval controls that provide an extra check to ensure all changes have followed your described process.

ClearQuest deployment database configuration

You can create a separate schema that specifically addresses code migration into your environments. There are some key factors that will make this a successful process when implementing a solution as follows:

• A central group that controls all deployments into the environments, starting with the test environment
• The deployment request system must have approval capabilities
• The capture of required information needed for SOX compliance
• The use of baselines created in ClearCase and used in ClearQuest records to identify the deployment number

1. Captured information: Initially, capture the project name, necessary deployment date, environment transition, and the baseline version name, as shown in Figure 16.
   
   Figure 16. Key information for schema
   
   
   
2. Additional captured information: Figure17 shows information that is useful for the SOX compliance team because it captures the approval information and testing information.
   
   Figure 17. Additional schema information
   
   
   
3. State matrix and useful controls: Figure 18 shows that the workflow to control deployments can be in a very simple format.
   
   Figure 18. A simple controlled workflow
   
   
   

The key areas to look at are the baseline build number and the completion of testing.

Putting it all together

There is a lot of information in this article that can quickly overwhelm you. This section will try to bring all the parts together in an easy-to-understand manner.

First, in order to meet Sarbanes-Oxley compliance you should adopt processes and procedures that will enhance your change control process while including your SOX objectives as a secondary concern.

All members of a QA group or senior management want the ability to track changes to the system from the inception of the request to its implementation. Without this ability, any organization should be worried that undesirable changes could get introduced into the production environment and thus cause damage to the business. If you use ClearQuest and ClearCase in a Unified Change Management solution, the controls are available for you to implement.

In general terms, here is the process of a request from inception to implementation:

1. A request (defect or enhancement) is entered into a ClearQuest database
2. The request is analyzed to determine if it is valid and is then assigned to the Change Control Board
3. The CCB reviews the request and approves it for a release of the software
4. The request is assigned to a development project and the PM reviews the request to determine who will implement it. If it is more than one developer, the PM creates child tickets and assigns them. If it is just one developer, the PM assigns the original ticket to them
5. The developer checks out code to be modified on the request and completes the change; te new code is then sent to the integration stream to be included into the next build
6. The build manager creates a baseline and updates the request to reflect the "build number." If the request has children, the ticket remains open until all children are completed and sent to the integration stream
7. The build manager opens a request to move the build into an environment by obtaining the correct approvals and providing complete information required for deployment
8. The deployment team moves the code into the environment and updates the ticket to show that it was deployed

Sarbanes-Oxley audits

When being reviewed for SOX compliance, one of the main areas that the team will be analyzing is a demonstration that only approved changes are implemented into production. The auditing group would at a minimum, seek out 25% of the change requests for the last 6 months and want to be able to follow their trails from start to finish. By implementing the concepts mentioned here and using ClearQuest and ClearCase, your audit should run smoothly.

SOX audit information gathering

Standard queries

In this section I will demonstrate some standard queries that are useful during a SOX audit and areas to focus on when creating them. This is by no means all of the queries or reports that may be required; however, it will give you a feel for what type of information is available to auditors.

ClearQuest and ClearCase change queries

Using ClearQuest as the change management medium will provide you the opportunity to create a multitude of queries that can retrieve information quickly and accurately.

• Question 1: Are changes approved for the current production release?

Create a combined view query that is keyed off the Release field for the specific month in question, as shown in Figure 19, below.

The Query Editor has the following filter:

Figure 20 shows that the request was approved for the specific month and implemented in that month and build.

• Question 2: How do you verify that the changes in the code correspond to the changes requested?

For this specific question, we will turn to ClearCase and extract the build (baseline) information for the release in question against the previous release. This will give me a list of all activities with code associated to a change from the previous build. This list should match the list in ClearQuest to show approvals. You can use the ClearCase Project Explorer to gather the information as follows:

1. Right-click on the component, and click Browse Baselines, as shown in Figure 21:
   
   Figure 21. Browse baselines
   
   
   
2. Compare the baselines from current production to the previous release, as shown in Figure 22:
   
   Figure 22. Comparing the baselines
   
   
   
3. Compare returned list to ClearQuest query, as shown in Figure 23:
   
   Figure 23. Comparing the returned list to the query
   
   
   
4. This utility will also show all changes to the code, as shown in Figure 24:
   
   Figure 24. Code changes in baseline
   
   
   

• Question 3: Where are the deployment approvals for the application in production?

By having a separate ClearQuest database that handles deployments, you can quickly show the deployment request and the approval for deployment. Figures 25, 26, and 27 show the approval and history for the change request.

Summary

This article has tried to touch on specific information about the use of ClearQuest and ClearCase for Sarbanes-Oxley compliance. Hopefully, the ideas and processes mentioned here will assist you in the control of your current processes and procedures.

One more thing to mention is that with Sarbanes-Oxley, any changes introduced into the production environment is considered a change, including new development. You can adopt the same processes used in this article with some minor modifications.

For new development, you can capture the requirements in RequisitePro and then generate tasks in MS Project once they are approved. Once they are in your MS Project Plan, you can then use the ClearQuest to MS Project interface (ProjectTracker) to generate "Activities" for the developers to associate with their code changes. This process will ensure that you can easily show the relationship between the BaseCMActivity to the approved requirement in RequisitePro once a developer starts working on an activity.

Resources

Learn

• Software Configuration Management Strategies and IBM Rational ClearCase: A Practical Introduction (2nd edition, IBM Press 2005) by David Bellagio and Tom Milligan provides a comprehensive review of CM strategies and practices with a UCM focus. This second edition is the updated and expanded version of Brian White’s popular book.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Learn more at the Safari Bookshelf, a fully-searchable virtual library that houses a vast collection of technical books from industry-leading publishers.
  
  

Get products and technologies

• To learn more about IBM Rational products, visit the developerWorks Rational zone. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
  
  
• Find more resources for ClearCase users and administrators in the ClearCase area of the developerWorks Rational zone, including articles and whitepapers, plug-ins, scripts and triggers; and links to training, discussion forums, product documentation and support.
  
  
• ClearQuest users and administrators can find more resources in the ClearQuest section of the developerWorks Rational zone, including ClearQuest hooks, Eclipse plug-ins, product documentation, articles and whitepapers.
  
  

Discuss

• Find a user group in your area from the Rational Global User Group Community. Rational User Groups are independent, user-run organizations that provide an open forum to promote information exchange between customers and Rational staff.
  
  
• The ClearQuest discussion forum on developerWorks is a great place to post questions and get answers about change management with IBM Rational ClearQuest.
  
  
• The ClearCase discussion forum on developerWorks is a great place to post questions and get answers about configuration management and UCM with IBM Rational ClearCase.
  
  

About the author

Tony W. O'Neill is currently managing the Quality Assurance Group at Liberty Mutual Agency Markets in Indianapolis. He has been an administrator and advocate in the use of IBM Rational tools for over 7 years and has implemented the solution in several major companies in the area. His current focus is using the IBM Rational tools to verify project quality and project health within the organization.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Using ClearQuest for change control in SOX compliance
• ClearCase code migration and management
• Putting it all together
• SOX audit information gathering
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational ClearCase
• Demo: Unified Change Management using ClearCase and ClearQuest
• Briefing: Quality driven software delivery
• Buy: Rational ClearCase

My developerWorks community

Dig deeper into Rational on developerWorks

Cloud computing for developers

Virtual workshop: Learn how to build a cloud infrastructure and develop/deploy cloud-based applications. (6-8 Apr 2010)

Special offers