Compliance Tips for the Guilty

Using Culpability Scores to Reduce Risk

NOTE: This article originally appeared in the March 2008 issue of Flawless Compliance, under the "Hello Rubber, Meet the Road" section. The link to the actual issue is at the bottom of this article.

Lora Bently, who is responsible for the Sarbox Survival Guide blog, uncovered a real gem this month. In her entry, "What Do Sentencing Guidelines Have to Do with Compliance?" she discusses a conversation that she had with the CEO Brett Curran of Axentis, a GRC ( Governance, Risk, and Compliance ) software manufacturer.

In a recent product announcement for Axentis, the company referenced guidelines for compliance from the U.S. Sentencing Commission. This is the agency responsible for establishing Sentencing Guidelines for people found guilty of certain federal crimes.

Compliance guidelines for the guilty? Doesn't it seem a little late to be giving these people advice?

According to Mr. Curran, these guidelines are used to assess a culpability score, and this score will determine the sentence that's delivered.

This is great to know. Let's use these guidelines as requirements for a new Compliance Data System.

First let's take a look at what they are:

1. Define policies, procedures, and controls.
2. Designate high-level people to manage the program day-to-day
3. Communicate policies, procedures, standards, and training to people periodically.
4. Audit and monitor the program periodically.
5. Periodically promote the program, and enforce it consistently throughout the organization.
6. Take action to prevent future problem occurrences.
7. Periodically assess risks and modify controls and policies.

Okay, obviously for an article this size we'll need to make some assumptions, and leave out some details, but I wanted to give you the high level of how this is put together.

A Compliance Data System is built using audit intelligence ( a derivative of business intelligence ) techniques, and I just published an eBook on the proper way to get started called "A Racehorse Without a Jockey". So consistent with that book, we start off by building a charter, stakeholder assessment, preamble, and elevator speech.

From this exercise, let's clarify exactly what we're trying to do here. The Project Objective would read something like this:

Develop a Compliance Data System that clearly demonstrates that we are following all 7 of the suggested U.S. Sentencing Guidelines that were promulgated in 1991 by the U.S. Sentencing Commission. The system should be in place before the end if this fiscal year.

The key point of clarification here, is that we are not trying to fill gaps here. The assumption is that we are already doing all of these things, and the goal of the new Compliance Data System is to prove that we are doing these things.

So, with that done let's revisit the requirements, because I don't like some of the vague language. Here's some clarifications we will make to move these requirements closer to "operational definitions".

• For Number 2, let's call "high-level" anybody in the organization that is a "Vice President", or has one that reports to them.
• In general, the term "periodically" means every month.

The next thing to understand, is that the Compliance Data System looks and feels more like a data warehouse than a transactional system. Therefore, we will have sources, transformations, and the target will be our new Compliance Data System. We will call it SBCS ( Sentencing Based Compliance System ).

Next, let's take a look at our sources.

• For rule #1, let's assume that there are 7 business units, and each one has their own web-based repository where policies, procedures, and controls are stored.
• For rule # 2, the management assignment is done, but not automated. It goes something like this, "Okay, Mary? You're managing this now."
• For rule # 3, the communication effort is somewhat organized, but also not automated.
• For rule #4, internal audit has a transactional system called IASOR ( Internal Audit System of Record ) where it records the results of its audits.
• For rule #5, this is managed through their learning system TEACH, along with the rest of the corporate training classes.
• For rule #6, a system called REACT has been installed to track risk events, and their resolution.
• For rule # 7, an organized review is done monthly, but not automated.

To complete the architectural bridge from our existing source systems, to our target system, we will need to add the following components:

• A consolidation point for the 7 BU web repositories. We will use an SOA architecture to pull information out of each of the existing web repositories, and deposit data ( via web service ) into our collection point.
• A lightweight transactional system that ties into our existing HR database, to tie up the loose ends from the stuff that is not yet automated. It will formalize and record who is managing the program. It will also manage the communication plan, including who needs to be communicated to, what needs to be communicated, how it gets communicated, and when the communication happens. Finally, it will formalize the risk assessment and control improvements. This system will be called AuditLink.

The only step left is our transformation logic. Here are the highlights:

• Since we have the consolidation point for the 7 business units' policy repository already, the only thing we need to do is push this over to the target. You can either store the whole policy in SBCS ( the new data system ), or a link to where it can be found.
• Since we are building AuditLink from scratch, we have the advantage of knowing that it will be downstreamed by SBCS. The transformations will consolidate who is managing what, with appropriate titles.
• Communication events are transferred to SBCS as they happen through AuditLink. SBCS consolidates the what, when, and who.
• Data from IASOR is transferred directly to SBCS as audit results are recorded there.
• The TEACH system is polled for select audit related classes, and pushed down to the SBCS. Changes are monitored and recorded as they happen.
• The entire REACT database is polled and incidents are transferred to SBCS as they happen.
• Risk assessment and control enhancement is sent to SBCS once the monthly audit is recorded in AuditLink.
• The SBCS is updated with this information on a daily basis, and all the change history is stored. "Tiny steps" are made so that there is a clear audit trail, and all evidence is captured to support the transformation logic.

Once the Compliance Data System transformations are complete, a set of batch reports are built to run against the new system. These batch reports resolve the objective of clearly demonstrating our compliance.

I hope this gives you a sense for the role of the Compliance Data System, and how you go about making it happen. Using our sentencing guidelines and this architecture greatly reduces your chances that any sentencing happens at all.