Hard-Boiled Compliance

How to Help Your Company with Financial Risk

NOTE: This originally appeared on this date at Quest Software's ToadWorld, on the expert blog "John Weathington's Quest for Compliance". The link to the actual ToadWorld article is at the bottom.

Risk is a topic that’s being talked about a lot lately, especially in the financial / SOX arena. Here’s why.

New SEC Standards Mean Risk is the Way

When SOX first rolled through, the focus was purely on rule-based controls. That’s because GAAP ( Generally Accepted Accounting Principles ), the guideline that is used for the more salient SOX related exposure, is a rule based system. Meaning, the FASB ( Financial Accounting Standards Board ) determines the proper ways to do accounting, then creates rules that must be followed. Good companies follow the rules, and don’t have SOX problems, because the SEC ( Securities and Exchange Commission ) has determined that as long as GAAP rules are being followed, public companies are in compliance with SOX ( at least that section of SOX ). This was in the early days of SOX, when AS2 ( Auditing Standard 2 ) was the guideline of the day.

AS2 has been recently superseded by AS5 ( Auditing Standard 5 ). This was mainly in response to the overwhelming concern by the big companies that had to go through SOX compliance, that the process was too costly. AS5 attempts to remedy the situation by introducing the concept of a risk-based, top-down approach to control. In theory, this should reduce the cost of compliance for your company (although recent studies have shown that this is not proving true ).

AS5 carries both good news and bad news for your company. The good news is that they don’t necessarily need to worry about all the rules that drive every line item on their financial statements. This is the risk-based portion of the standard. Your company is at liberty to focus only on the high-risk items, and for all intents and purposes ignore the low-risk stuff. The bad news is that your company has to do some work on financial risk analysis, which they’re probably not used to.

How This Relates to Database Professionals

This is where you come in.

As usual, there is a great deal of value you can provide in helping your company conduct its financial risk analysis and further justify its decisions. I just read today that over half of the CFOs that are attesting under AS5, are unsure of what financial items to consider as high risk. I guess this presents a problem, when trying to follow a standard that’s predicated on a risk-based approach!
So, before we design, let’s reflect on what constitutes financial high-risk in the eyes of the SEC. The overriding risk for all of SOX compliance is that there are financial inaccuracies in the published financial statements. These are the numbers that the investors trade on, and the SEC is holding your company’s CEO and CFO responsible for making sure these numbers are right.

Earlier in the year, we discussed the different ways to control risk ( Reconciliation, Approvals, Segregation of Duties ), and the risks that involved with these controls. We’ve also talked briefly in Prevention over Intervention, about some design considerations for a compliance data warehouse. The natural extension would be a compliance data mart. A compliance data mart is a subsystem of your entire compliance data system. As you might suspect, the compliance data mart is used for strategic aggregation and reporting of compliance data.

The Financial Risk Compliance Data Mart

One design consideration I have for addressing financial risk in your company, is to build a compliance data mart that specifically addresses this concern. It’s a big enough concern to warrant such attention. The goal of the data mart, is to provide a strategic reporting environment where auditors and finance executives can analyze the company’s ability to report accurately.

You would follow a typical star schema format. The fact table would contain data about exceptions / violations that were caught in the upstream components of the compliance data system. For instance, you may have a reconciling control in place that catches when balances are out of sync. Or you may have designed in an approval control to catch the risk of people making mistakes.

If you’ve been following my advice so far, in any and all of these cases, you should have a violation or exception table that highlights control violations. This is the data that you will aggregate in your fact. A metric such as violations per day is a great example of something to capture. You can also feed in data from previous audits, where the auditor has found discrepancies.

Of course you would also have dimensions. Some typical dimensions would be: period, financial item ( i.e. gross revenue, depreciation expense, etc. ), exception type ( i.e. recon, approval, SOD, etc. ), business unit, and others that seem to make sense for your organization.

Once the star schema is in place, create reports against it that highlight the areas that are financially risky for your company, from an internal control standpoint. This data will be extremely valuable to your finance executives, and will give them a platform for justifying what they call “high-risk” on their financial statements. Of course there will be other interpretations of high-risk, but your approach will provide a very objective base to drive from.

In Summary

You’ll be hearing a lot more about risk in the compliance arena, as the industry starts moving more in that direction. Financial risk is just one example of something your company is probably trying to wrap its arms around. The introduction of a Financial Risk Compliance Data Mart, a data mart that highlights risky areas of the financial statement, can be a great asset to your company’s financial executives. Take some time today to explore this with your finance and / or audit team.

...read the article on ToadWorld

Whole Lotta Shakin'

Southern California was hit by quite a shaker today. According to Reuters, A 5.4 magnitude earthquake rolled through Chino Hills at about Noon today. Originally we thought it was a 5.8, but it has been recently downgraded.

Although it set off a lot of building alarms, there have been no injuries or significant damages reported. Here's what the report says:

"In California, fortunately because of our good building standards we would not expect to see structural damage with a (magnitude) 5.4," said Kate Hutton, seismologist at the California Institute of Technology.

This is very true. If this had happened somewhere else, it may not be such a rosy picture. That's because, as everybody knows, this is the land of earthquakes. The only people really shaken up are the people that are either visiting, or haven't lived here very long.

I'm not terribly familiar with the construction industry, but I'm pretty sure that the building codes that we have, make construction projects in California more expensive, more time consuming, and more work in general. I know a few years ago, it cost me about $1000 just to get a new water heater installed, because the regulations require more diligence, such as safety straps to secure it, so that an earthquake doesn't knock it loose.

We don't like it too much, but we know that any time an earthquake can roll through and make our lives even more difficult. So it's worth the expense up front, and it's good to know that our bridges and buildings are built with these concerns in mind.

Understanding why your company needs to comply with certain regulations, guidelines, or even internal policy is the key to commitment. You need to explain the risks, and the impact of the risks, so that people aren't just focusing on the "pain" of compliance.

Don't let an earthquake destroy your company. Pay the price for proper compliance, and make sure your company is on board by explaining the risks.

Picture Source.

The Emporer's New Compliance Program

I've recently been talking with investment advisers about their compliance practices. What's funny is that although none of them have any relation to each other, I picked up a pattern in the basic message that they were communicating to me.

Apparently, they have no issues with compliance. Somewhere in the "back room" there's a battalion of compliance experts incessantly combing through tombs of compliance books, regulations, standards, statements, advisories ... you get the idea. All this is diligently codified, and translated into bulletproof processes and super-systems that do not allow them to go out of compliance.

That's why I thought it was hilarious to come across a recent post by Wendy Fried at footnoted.org. Apparently, the SEC just issued a ComplianceAlert to SEC regulated companies including broker-dealers and investment advisers. According to Wendy ...

SEC examiners found some large broker-dealers to be surprisingly sloppy about verifying the values their trading desks assign to subprime mortgage-related products ...

... At certain unnamed broker-dealers, subprime securities held as collateral for financing transactions were “solely priced by proprietary traders and/or outside pricing services,” with zero oversight by the personnel who were supposedly overseeing these valuations. It’s rather troubling that, at a moment when dealers are presumably on high alert about the financial health of their counterparties, any firm would hold subprime-related collateral and not be totally anal-retentive about how it’s valued.

This does not surprise me a bit. Here's the real truth people.

If you do not have a system in place to tell you that your process is doing what you think your process is doing, it's probably not. When I investigate a company's process control, in almost every case, their "as-is" process has discrepancies, sometimes huge discrepancies, with their "really as-is" process.

If you're the Emperor, and you are being told your compliance is under control, look in the mirror before you decide to walk down the street.

Wet Clothes in the Dryer

Part of our recent remodel effort was junking the old dryer that didn't work, and getting a shiny new one. I hated the old dryer because it wouldn't dry clothes ( I guess the primary function of a dryer ). We would have clothes in for hours at a time, and they still wouldn't dry.

As you can imagine, I was jumping through my skin last year when we went shopping for a new dryer. We settled on the Whirlpool Duet. Even before the utility room was done, I told the contractors to hook it up, because I couldn't wait.

They hooked it up, I did a load a clothes, and wouldn't you know it ... wet clothes again! I tried it again ... more wet clothes.

As it turns out my dryer vents are currently clogged. Simple enough, I just called the dryer vent unclogger company, to come out and unclog the vents. Well, they came out, but they didn't unclog my vents. Reason being, The outlet to the dryer vent is right under my brand new deck.

I'm sorry, but nobody's cutting a hole in my brand new deck to clean out my dryer vents.

So, now it's the end of July, and I have a brand new dryer that won't dry clothes.

The objective was clear -- dry clothes, however with all the time and effort I put behind getting to the objective, I still don't have it.

This will certainly happen on your compliance projects. The key is to stay clear on the objective, make sure you're taking intelligent actions toward the objective, and adjust when your these unexpected risks show up. You also need a good risk plan, so you can absorb the losses, and have the capacity to adjust.

The good news is that when we get our new HVAC system in, they will clean out our vents for us for free. Look for opportunities like this on your project, when things do go as expected.

For the time being, I'm going to use my dryer as a rack to air-dry my clothes. 

Coping with Disaster

NOTE: This originally appeared on this date at Quest Software's ToadWorld, on the expert blog "John Weathington's Quest for Compliance". The link to the actual ToadWorld article is at the bottom.

Over the last couple of months, we’ve been discussing different types of controls, and how they might fit into the architecture of your compliance data system. We’ve already discussed preventive controls, contingent controls, and corrective controls. To round out our discussion, today we’ll be discussing our final category of controls – adaptive controls.

If you’ve been following my recent discussions on controls, you know where these controls sit in the overall framework of controls as I see it. For the benefit of those who haven’t, I’ll briefly describe what an adaptive control is.

An adaptive control is a control that deals with the impact of a risk event, after the risk event has occurred. Let’s consider the risk of a power outage. What would happen if the power went out while you were watching TV at night? What would be the impact? Of course, you wouldn’t be able to see. Not being able to see can have other uncomfortable consequences like stubbing your toe, however we’ll just stop there for a moment – not being able to see is a bad enough impact.

To control for this, we could light a candle or better yet a flashlight. In this sense, we are adapting to the situation. You could build the argument that there was some contingency controlling on your part by having a candle or flashlight ready for an emergency, and you would be right if these things were consciously put in place, specifically to address the risk of a power outage.

This is not what I’m talking about.

In my scenario, you didn’t plan for it, but you still knew where to find the flashlight, and fortunately the batteries that you put in it last time when you were crawling under your house, are still working.

It’s important to understand the distinction. Corrective and adaptive controls are reactive in nature. For this reason, I don’t like these controls as your primary system of defense against risk. That said, they are still necessary for the same reasons that we covered when we talked about corrective controls; as a backup for better controls, in case it’s not feasible to install better controls, and handling the consequences of a risk that was purposely ignored.

Corrective vs. Adaptive

So, if you have the choice of using a corrective control ( addressing the cause of the risk ), or an adaptive control ( addressing the impact of the risk ), which should you prefer? You actually need both, but you should exercise the adaptive control first. This is the equivalent of “stopping the bleeding.” After your adaptive efforts have contained the situation, then your corrective controls should kick in so your metrics can eventually be improved. An alternative would be to launch both in parallel, if you have the resources to do it.

Leveraging Corrective Control Architectures

If you’ve gone through the process of integrating some of the suggestions that we’ve discussed for corrective controls, this will add a lot of value to your adaptive control setup. If you remember, we discussed three architectural considerations; a detection system, tracking system, and metrics system.

You will need to leverage both the detection system and the tracking system. The metrics system is not useful for adaptive control system, as you are not trying to improve your compliance -- you are just trying to bandage the impact.

Just like the corrective control system, you will need to quickly detect that a risk event has occurred, and start tracking actions. The goal of the actions is different however, and the response time more critical.

The business will need to come up with an ad-hoc, temporary process to support the business goal. Let’s use another example – a SOX example this time. Let’s say your business is trying to control the risk of a bug in the reporting system throwing the numbers off. The impact of this risk is financial inaccuracies in the official financial statement.

Your system is running fine, until one day your detection system fires a warning. Some balancing assertions are failing in the Latin America reports, so something’s wrong with the system. It will take a few months to correct the problem, but in the meantime, an adaptive control needs to be deployed. The adaptive control is to have finance people manually comb through the Latin America reports, and fix any errors before they make their way to the official financial statement.

Key Considerations for the Adaptive Control System

The key to your adaptive control system is being able to document the actions taken to reduce the impact of the risk. This will give your company a reference database, in case this risk event shows up again.
Furthermore you need to collect some metrics for understanding the impact to the organization of exercising the adaptive control. Important metrics to consider are the time it takes to handle the impact, the degree to which the impact is contained ( in our example, 100% ), and the cost to the organization for implementing the control ( both initial and ongoing ). This type of reporting will highlight the premium your organization is paying for having this risk show up. Stated in other terms, this is the alternative impact of the risk – the price you pay for avoiding the primary impact of the risk.

In Summary

Adaptive controls are another weapon in your arsenal of controlling risk. Like corrective controls, these are reactive, so you can leverage a lot of the architecture already established. The key however in designing support for your adaptive controls, is making sure adaptive actions are documented, and proper metrics are collected. Creating a framework for your business users to track this information is vital to their overall compliance efforts.

...read the article on ToadWorld

3 Key Tips for Surviving a Firefight

NOTE: This originally appeared on this date at Quest Software's ToadWorld, on the expert blog "John Weathington's Quest for Compliance". The link to the actual ToadWorld article is at the bottom.

I just wrote an article in the latest issue of my newsletter Flawless Compliance(tm), about the fires that continue to blaze around Big Sur in California. Out here, it’s on everybody’s mind. We’re constantly reminded of the fire departments’ victories and defeats, as the battle to contain the fire continues.

We face similar situations when compliance situations get out of control. In a perfect world, everybody would be proactive in their compliance efforts. There’s plenty of education and assistance out there, so there’s no reason why companies can’t do it. However, they unfortunately don’t do it until it becomes a problem.

Reactive compliance efforts are in a class by themselves. Suppose a recent audit discovered serious compliance violations. Your company will be responsible for immediate remediation, with serious impacts if it’s not done. I know, we’ve all been there late nights trying to hit an unrealistic deadline, but it’s one thing to disappoint Marketing, and a whole different animal to miss a remediation deadline.

As a database professional, you might be dragged into these efforts, so I wanted to share some of my favorite tips for getting through. If you’re not prepared, you are setting yourself up for undue stress, frustration, and long hours.

Tip # 1 : Get Good Tools, And Learn Them Well

By far, Toad is the best tool to have in a firefight. You may have others, but this is your key tool. When firefighters go in to fight a fire, they’re not carrying garden hoses. I see the equivalent of that when I enter companies trying to battle serious issues that involve databases, and the best tool they have is SQL*Plus.

If your company doesn’t have Toad available, pay for the latest version of Toad out of your own pocket, and learn it inside out. I know that’s easy for me to say, because I’m a consultant, but I would strongly urge you to take my advice. The cost is nothing compared to the value it’s going to bring to your life.

I have to do on-the-spot data transformations from time to time. One time, I had a monstrous query that was taking about 3 hours to run (thank God it finished). I had to run this query over and over again, firstly because the transformations needed to be constantly tweaked to get the right results, and secondly because we had to run it over several periods of data. One pass through the Toad’s SQL Optimizer, and my 3 hour query was reduced to a 2 minute query. This saved me huge amounts of time, stress, and most importantly got the result to the client much quicker.

Tip # 2 : Don’t Take Things Personally

People in program and project management are typically not at their best when compliance impacts are involved. Understand it from their point of view. They are being held responsible for preventing the company from feeling a great deal of pain. The longer the threat exists, the more panicked and stressed-out everybody gets.

If you internalize this stress, you will not be able to perform. I’ve been screamed at, threatened, and forced to listen for hours at a time about how bad things are.  Although the language may indicate it, they are not reacting to you the person, they are reacting to the situation. Under normal circumstances, they probably wouldn’t act this way.

Database analysis takes focus and intellect. Your emotions can diminish your capacity to perform. Program and project managers typically don’t have this problem, because their job is to attend meetings, and communicate status. This does not require the same amount of intellectual firepower, as building a set of transformations to mine data for discovery. They can afford to stress out if they want to, you cannot.

So, stay cool and don’t take anything personally.

Tip # 3: Keep Grounded in Reality

What tends to happen is that you are pressured to commit to something that’s not reasonable. The stakeholders in your effort will want to believe something that’s not true. That’s the nature of the beast. Nobody wants to be out of compliance, and the sooner you can be in compliance the better. Once again, I know everybody wants everything on unrealistic deadlines – but this is different. There are serious consequences involved here, so the pressure is more intense.
Because you are committed to the solution, and helping your company resolve its issues, you will want their reality to unfold also. You may start convincing yourself that things are possible – when you know they are not probable. This is very dangerous.

I was on a project once, where the program management would not let up on a deadline. They said, “There is no other option, we must have it done by this date.” They actually communicated up to their auditors that it would be done. Unfortunately, all this was a fantasy, and I knew it from the beginning. They wanted to get something done in 6 months that was easily a year project. Of course, they blew the deadline, and things got exponentially worse. That’s what happens when you don’t pay attention to reality.

Stand your ground, and listen to your head instead of your heart. Do not sign up for something you cannot do, and push back hard if necessary. You are doing a great service when you don’t cave in. If you commit and don’t deliver, you harm everybody involved including yourself.

Getting caught in a firefight is no fun, and the compliance varieties are the worse. You can however limit your stress and frustration by taking a few pieces of good advice. Get good tools and learn them well, stay cool under pressure, and stay grounded in reality. If you don’t have the current version of Toad, purchase it today, and learn it inside out. That way you’ll be prepared when you’re called into action.

...read the article on ToadWorld

Flawless Compliance Newsletter - July 2008

The July 2008 issue of Flawless Compliance is available, with Center Stage article, The DOJ's Opinion on FCPA, Halliburton's Concession for Confession -- Is It Fair? Plus, the fires in Big Sur blaze on, a look at anti-corruption compliance, a hedge-fund CEO turned fugitive is in the soup, and an ingenious coffee cup teaches us about controls.

... read the July 2008 issue of Flawless Compliance

How to Correct a Bad Situation

NOTE: This originally appeared on this date at Quest Software's ToadWorld, on the expert blog "John Weathington's Quest for Compliance". The link to the actual ToadWorld article is at the bottom.

I’m doing sort of a skip series here on control architectures. A few weeks back, we discussed the golden child of controls – the Preventive Control. Then, a couple of weeks ago we tackled the second best option – the Contingent Control. Now, let’s take a look at the Corrective Control.

I’m not going to say it’s the third best option, because by the time we get this far down the road, it’s not worth ranking anymore. If you’ll remember our discussion on contingent controls, the reason why we preferred contingent over anything else, was because it’s dealing with a situation before a risk event occurs. Therefore, any proactive activity you can take to get risk under control is the best course of action.

So you might think we’re entering a loop in logic, because we’ll be discussing a type of control that is reactive. Meaning, the risk event has already happened. And, since we’re discussing architecture, that in itself implies that we’re planning for something. So how can this be reactive? I recognize this upfront, and I promise you that things will clear up before the end of the article.

So, in the reactive category of controls, we have corrective and adaptive. The difference between the two is the risk property that we’re dealing with. Corrective controls deal with the cause of the risk, and adaptive controls deal with impact. In our previous fraud example, the corrective control would be the huge fines and penalties inflicted on the evil-doers that caused the mess.

Building a Case for Corrective Controls

But before we jump into architecture, let’s answer a question that might be on your minds right now. If we have good, preventive controls in place and maybe even some contingent controls, do we even need to worry about corrective controls?

The answer is, “Absolutely,” and here are three reasons why:

1. You need to control for the risk that your preventive control is not effective. You can and should do this with a corrective control. This is actually the most common reason for installing corrective controls.  I did an article one in my newsletter Flawless Compliance(tm), where we talked about the college campus shootings. The college thought they had good preventive controls in place, but it turns out those controls failed. A corrective and / or adaptive control is the only thing to consider at this point.
   
2. In some situations, you cannot install preventive or contingent controls. Think about an earthquake taking out your only data center. You cannot prevent an earthquake, and you don’t have enough money to install a mirror site outside of California for disaster recovery.
   
3. In some situations, you will purposely decide not to control a risk ahead of time. In your initial risk analysis, you may have determined that the risk was either improbable, low impact, or both. Consider a risk with a very low probability but a somewhat high impact. If you decided to ignore this risk, and it shows up in spite of the low probability, then you have an issue.

I hope I’ve presented a strong enough case for you to at least consider the importance of corrective controls. I have three design considerations that you might want to put in place.

For Starters – How About a Detection System

If you compare my view of controls to others’ like Oracle GRC, you’ll find I’m a little more particular in the classification. That’s because I’m looking at it from a different point-of-view, and I feel the distinctions are very important. In the Oracle GRC world, you have controls that are classified for prevention and for detection. I believe detection is good, but you should not stop there. Oracle’s definition of detection is actually a subset of what I would consider a full corrective control.
Nonetheless, I like the idea. A detection system will attempt to flag assertion violations. When things are supposed to be a certain way, an assertion is made. For instance, Balance A should match Balance B. A detection system will try to identify situations where this isn’t true. In Keep it Under Control with Reconciliation, we discuss some great architectures for controlling situations like this.

You may argue at this point, that building a system upfront is a planning activity, which disagrees with our definition of a corrective control. As promised earlier, I’ll clear that up for your right now.
It is important to separate the act of reaction, with the infrastructure that adequately supports the capability of reacting. Remember, in our detection system, if a violation is identified, there’s nothing you can do to undo that. You are catching the violation after the fact, and hopefully you will do something about it, so it still falls under the category of corrective. The key is knowing that something like this might happen, and enabling your business users to react properly.

A detection system is the first enabler, but what else can we do?

Uh Oh, Now What? – How About a Tracking System

Your business now needs a way to track what happens after the violation occurs. Consider a ticketing system, similar to a help desk. This will be different from a contingent control, in that there is no predefined process that should be taken. So, instead of making sure a contingent plan is followed, we want to make sure a generic plan is followed. Once again, you can leverage what we discussed in Automated Process Auditing, or develop something simple purely for this purpose.
Like a help desk application, the system should track the violation that created the ticket, who it’s assigned to, who’s ultimately responsible for the corrective process, when actions are taken and by whom, and some comments on resolution. You can use your corporate practices and common sense to fill in the rest, but you get the idea.

How Well Did We Do? – Ask Your Metrics System

The purpose of any corrective action is to improve your compliance metrics. That implies that you have compliance metrics that are religiously being tracked. Of course the best way to do that is in a data system. I suggest a Compliance Metrics System.

Track metrics that demonstrate how well your compliance is doing. Metrics such as # of violations per day, are key in the visibility and transparency of your compliance operation. To enhance the metric system, also track when corrective controls were executed, and how they ( hopefully ) improved your compliance picture. Objective analysis like this can unequivocally demonstrate that responding to your violation with your corrective control made a significant difference to your company’s operation.

Corrective controls are another area of consideration, when designing your compliance data system. Don’t overlook their necessity, as they may be required in cases where other types of controls are not possible or feasible. Architecture considerations include detection systems, tracking systems, and metric systems that demonstrate improved compliance. A detection system is a great initial step. You can start designing one today.

...read the article on ToadWorld

IT Independence – How Much Centralization is the Right Amount?

NOTE: This originally appeared on this date at Quest Software's ToadWorld, on the expert blog "John Weathington's Quest for Compliance". The link to the actual ToadWorld article is at the bottom.

Happy Independence Day!

On this festive occasion, which celebrates our independence as a nation, I saw it appropriate to discuss the independence of Information Technology in a corporation’s compliance program. In other words, how much centralization is a good thing, when it comes to pulling off a compliance effort in your company?
Compliance aside, this debate has been going on ever since the birth of IT. I feel the classic answer of, “Well, it depends,” is a cop out for the intellectually curious to debate over for hours, days, or even months, without moving an inch forward on a consensus.

So, is IT independence a good thing for a company’s compliance efforts? In general, the answer is “No.” Of course complete decentralization is not the answer either, however in my view the gauge favors decentralization over centralization. To help you see my point, let’s look at some advantages and disadvantages to both sides of the scale.

The Advantages of Centralization

The biggest advantage to centralization is IT governance. You might find it odd that I’m a proponent of decentralization given that IT governance is core to my business, but I have to call it straight. When IT is centralized, it’s much easier to get IT governance under control. Having the control and influence that centralization affords, is key to governing the operations that IT performs. Even data governance is easier to manage with a centralized effort, as it’s easier to catalog your data when your scope of visibility is wide. This can only be accomplished in a centralized operation.

Aside from IT governance, IT centralization helps the IT function run in an efficient manner. If you view IT as a service business with a set of processes, it’s much easier to get your processes under control and lean (elimination of duplication and waste) when things are more centralized.

Finally, centralization allows the concerns of IT to be organized and enforced. There are certain things that are good for the organization, that nobody else but IT will worry about. For example, the business may not realize that running your compliance system on a Microsoft Access database is a bad idea!

The Advantages of Decentralization

So, let’s now discuss the reasons why a tendency toward decentralization is the best way to organize your IT function. The number one reason why decentralization is important is because it affords the best alignment with the business objectives – in our case compliance. IT is a support function, and that needs to be remembered. Data systems cannot build themselves. Even with talented architects, if you ignore the real business need, you’re just practicing your skills on something that has no value to the business. Even if you think you know what’s best for the business, that’s not your role.

My lovely dog is a perfect example of how I see some IT shops work. I love her to death, but she really has a mind of her own. We don’t give her commands – to her they’re “suggestions.” One day we were all out in the front yard, when her sister, the instigator, took off running for no apparent reason. Obviously we screamed, “Come here right now!” On this occasion, she decided that although this was a reasonable idea, it made more sense to follow her sister across the street and down the sidewalk. She came within a few feet of an oncoming car.

Don’t misunderstand me. I’m not saying IT is not valuable. In fact in my view, IT is the most important part of the equation. It takes a lot of skill to be an IT professional, especially one that’s involved in a compliance-related effort (because the stakes are usually high). Just remember however, that your skill and talent doesn’t translate to your authority to run the show. It’s a compliance problem you’re trying to solve, not an IT problem, so leave the requirements to the compliance specialists.

There are some other advantages to decentralization. In general, a decentralized organization is more flexible, which is vitally important in a compliance environment. As you may have heard me mention before, expect requirements on a compliance project to change – sometimes radically and often with very short notice. The ability of a decentralized organization to react to these changes is a big advantage.

Finally, for most IT people, being in a decentralized organization is just more fun. IT people are intelligent people that love to learn. Learning about compliance is actually very interesting, and it adds a great dimension to your breadth of knowledge. Being part of something bigger than IT, and seeing your efforts make an impact, is a very rewarding experience.

One Part Centralized, Three Parts Decentralized

 The best mix for me is one part centralization, and three parts decentralization. Don’t take this literally; it’s just a conceptual rule of thumb. You need to exploit all the advantages of decentralization, while taking advantage of as much centralization as you can.

To do this effectively, decentralize as much as possible, and build good metrics around your compliance function. Capture metrics that demonstrate how efficient your compliance function is, without regard for IT specific constraints.

At this point I would formally improve ( i.e. through Six Sigma ) your compliance program as much as you can while your IT function is completely decentralized. If done properly, you should have good control plans around your compliance processes, so you know what levels you should be operating at.

Then, and only then, start to centralize the IT function, watching your compliance metrics closely. The instant the efficiency of your compliance program degrades even a small amount, stop! Centralization cannot be allowed to encroach on your business’ ability to conduct proper compliance.

To Centralize or Decentralize, That is the Question

Well, you have my answer.

If you want the compliance efforts at your company to be the most effective, mix one part centralization with three parts decentralization. Your IT organization should be completely aligned with the compliance function of your company, flexible and adaptable to change, and the people should be having fun. This is not equivocal. With this specification firmly in place, you should strive to be as centralized as you can, eliminating redundancies and administering proper governance.

If your compliance efforts are not where they need to be, analyze your level of IT centralization. You may find that you need to decentralize a bit, to obtain optimum performance.

...read the article on ToadWorld