IT Management

Would you rather be given an endless stream of seemingly disconnected orders for time-consuming activities, or be issued a general requirement, then allowed to comply in your own way, at your own pace?

Almost everyone prefers the second choice, which is what this issue’s column is about. We will explore the paradigm that shapes documentation requirements for many IT- and data-related compliance initiatives. If you understand the paradigm, you should be better able to predict what will be required of you.

Just Do It

Back in the pre-Y2K days, many IT activities were considered “black-box” efforts—the business didn’t want or need to look inside. Given a mandate to build an application, the expectations were to “Just do it!” How, and with what level of documentation, were generally up to those doing the work.

However, when the Y2K compliance effort proved too costly and painful, businesses started expecting more transparency. Business leaders had been forced to glimpse into the black box, and they didn’t always like what they saw. They started chanting “Run IT like a business!” IT budgets were now expected to address TCO. Enter Sarbanes-Oxley (SOX)

With the advent of the SOX Act of 2002, affected company executives had to attest to the effectiveness of their internal controls over financial data. Auditors interpreted this to mean that financial systems had to be welldocumented, and corporate controls to manage risk to those systems also had to be documented; likewise, for processes that created and managed financial data, and processes to control risk to that data. In short, a new paradigm was born.

The Post-Compliance Paradigm Shift

While the paradigm before SOX had only one requirement (“Just do it!”), the Post-Compliance Paradigm has four: Do it, Control it, Document it, and Prove compliance! Here’s the reasoning. Auditors claim that if you haven’t proved compliance to them, they can’t issue an opinion that you are compliant. And your proof of compliance must be documented. In other words, if it’s not written down, it doesn’t exist.

What do you need to document? Here’s a basic pattern, which can be applied to more than just SOX efforts. Basically, for everything you do, you need three sets of documentation:

Governance documentation: This sets the tone for your organization’s approach to risk. How do you approach governance, risk management, and compliance? How are decisions made, and when, and by whom?

Management documentation: This describes your operational systems and processes. How are systems and processes acquired, implemented, tested, deployed, and maintained?

Controls Documentation: This describes your control environment and control activities. What risks to systems and processes have you identified, how are those risks managed, and how have you recorded your risk management efforts?

For each of these three areas, you need cascading sets of documentation.

First, you need one or more policies. A policy proves that the organization has stated its intention about what must be done, and what can’t be done. Next, you need standards. These can take many forms: lists of guidelines, system specifications, process flows, or other types of binding requirements.

Third, you need written procedures. The level of detail may vary, but you need some sort of proof of how your systems and people operate. And last, you need proof of execution of these procedures. This may include meeting notes, operational logs, audit logs, system screen shots, timestamps, or many other mechanisms.

The basic pattern of requirements can be pictured as three waterfalls (see Figure 1). For governance, operations and controls, start by documenting what you intend to do. Then, say how to standardize it, how to do it, and finally, how to record that you’ve done it.

 

If you keep the waterfall guideline in mind when you plan to acquire or modify a system or process, you should be able to better anticipate your documentation needs. And this ability should make compliance less painful. Z