In-Depth

Seven Strategies for Compliance Change Management

Driven especially by SOX, companies are turning to change management to provide needed discipline for changes to IT infrastructure and systems. To ensure the integrity of systems storing regulated data, as well as the attendant IT policies and procedures, companies are increasingly adopting change management practices.

• By Mathew Schwartz
• 02/06/2007

Can your developers, testers, QA personnel, database administrators, or IT managers make changes directly to production systems?

As companies seek to comply with regulations in a more demonstrable, repeatable, and cost-effective manner, they're increasingly studying which employees, and especially which IT employees, have direct access to IT systems. A focus of concern: direct access to applications utilizing regulated information, since any data-level change might go unrecorded.

To ensure the integrity of such systems, and that overall IT policies and procedures comply with regulatory requirements, companies are increasingly turning to change management. Simply put, this means pursuing a structured approach to all IT changes, to ensure they're needed, tracked, authorized, and ultimately, effective.

Experts say change management processes are essential for complying in a cost-effective, repeatable, and demonstrable manner with any regulation that has an IT impact, including HIPAA, Gramm-Leach-Bliley, and Basel II.

SOX Drives Change Management

Perhaps the biggest regulatory driver for change management practices in the enterprise, however, is Sarbanes-Oxley (SOX). "A big hit for SOX is change management—organizations need to stay on top of business, process, and IT changes that affect their IT systems," note Forrester Research analysts Michael Rasmussen and Paul Hamerman in a recent report. "This requires that SOX compliance become an ongoing process that is constantly being managed throughout business and IT change."

Change management practices are especially important for optimizing an organization's software development lifecycle (SDLC) operations. Companies with effective SDLC change management practices all have at least one thing in common: a clear separation of duties. "One of the fundamental premises of change management is to segregate duties from development, to testing, to implementing it in the production environment," notes Gary Baker, who leads Deloitte & Touche's IT governance practice in Canada.

In many companies, however, a clear separation of IT duties doesn't exist. "We often find organizations with developers having access to the production environment," he says. Such access is inappropriate because it can compromise application and data integrity in two ways: First, ad hoc changes are often imprecisely tracked; there is no trusted audit trail. Second, making changes directly to production systems, without thorough testing, may result in application instability, introduce security vulnerabilities, and lead to data loss.

Why Change Management Lags

Interestingly, the widespread lack of change management processes in regulated environments, specifically around the SDLC, often stems from a business requirement: to rapidly respond to users' requests. Thus, many companies allow their developers to make any necessary ad hoc changes directly to live applications.

Yet while that might seem like the easiest approach, it ultimately isn't efficient, or compliant. "More mature organizations don't have developers make those fixes," notes Baker. "They have a separate process, away from production systems, allowing their programmers to do more rationalized fixes in a development environment." Testers—coming in with "a cold set of eyes"—then vet the changes to ensure they're effective and run well, and then an operations group loads the changes onto production systems. All changes are documented, and managers sign off at every step.

Thus by better managing changes, organizations better comply with regulations, while also making more efficient use of existing resources. "If you have an ad hoc, chaotic system, while it may feel like it's faster, what ends up happening is you have to fix a lot of breaks, so you end up doing a lot of rework," says Baker. "Whereas if you put it through a managed process, you eliminate a lot of the rework." This holds for a SDLC, as well as any other IT process or procedure changes, such as updating compliance and security policies, creating a PC client build, or evaluating new enterprise software before adopting it.

Auditor-Friendly Changes

Exactly what should a change management program track? At least for the SDLC, auditors will want to see three things, says Ellyn Winters-Robinson, vice president of marketing for MKS Inc. First, "what was the original reason for the change, or the business requirement?" Second, "how was the change managed," and "did the developer or person who made the change in the software also promote the change?" (This should be avoided.) Finally, did the company properly audit the change? "That's where companies often slip up, when they hand it to production. Because that's where systems go down and there can be a serious impact to the viability of systems."

Even better than just tracking changes, however, is automating controls to enforce these processes. "As I remember from my math classes, if you want to prove something, sometimes it's easiest to prove it couldn't be otherwise," notes Philip Deck, CEO of MKS. Automated controls, then, help companies require authorizations before any hand-off, and maintain a trusted audit trail of all changes made.

Companies Turn to IT Frameworks

Beyond the SDLC, the precise make-up of an IT change management program will vary by organization. Even so, numerous IT frameworks exist to help companies get started, and many are now adopting them, says Baker. "What we're seeing is a lot of interest around best practice processes like ITIL, and control models like COBIT."

Briefly, CobiT (Control Objectives for Information and related Technology) is a widely used, higher-level IT governance framework. By contrast, the IT Infrastructure Library (ITIL) is "a service and process management framework," notes Forrester's Rasmussen. "It operates at a more practical level than CobiT does and is therefore of value for mapping controls to the processes for the management of IT systems that regulations require, such as change, configuration, and incident management." While use of CobiT predominates for companies in regulated environments—Forrester says half of its clients complying with SOX use CobiT—studies show ITIL's popularity is increasing.

Many frameworks, however, are complementary, especially for organizations pursuing change management. In fact, Baker recommends organizations balance operational controls (such as CobiT) with IT controls (such as ITIL), since having one without the other may exacerbate existing problems. For example, take companies who want to prevent developers from accessing production systems. "We've found that while the technical fix is easy—you can just turn those privileges off—that creates huge business problems, because those developers are there for a reason," he says. "They're creating and fixing things users want."

Avoid the Big Bang

As that suggests, when adopting IT frameworks, don't apply change management to every process at once. "Don't try for some big bang right away," says MLK's Winters-Robinson. For example, when it comes to improving SDLC practices for compliance purposes, "the companies who are most successful start by building version management, and basic development processes, then extend it into testing."

The same advice—pursue change in stages—holds for better managing any compliance-related process and procedure change in the enterprise. Simply put, all of the accompanying and necessary cultural, organizational, and technical changes won't happen overnight. In particular, the IT frameworks many organizations are using to create change management programs require careful consideration of the desired, end business processes, with changes made over time.

This is exacting work. "ITIL isn't easy," notes Andi Mann, a senior analyst at Enterprise Management Associates. "It's not something you can do in a day or a week, but it's worth the effort … because it helps your business run better. Then, almost as a side effect, it helps you be more compliant."