Jul 10

Written by: JohnWeathington
Thursday, July 10, 2008 

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.