Hard-Boiled Compliance

Flawless Compliance Newsletter - January 2009

The January 2009 issue of Flawless Compliance is available, with Center Stage article, Transparency 2.0, Welcome to the New Age of Compliance. Plus, compliance lessons learned from a heroic pilot, how your image effects the outcome of an audit, India takes its place in the global scandal line-up, and a fishy control that should have been tossed..

... read the January 2009 issue of Flawless Compliance

Black Box Data Store: Lessons Learned from the NTSB

US Airways flight 1549 teaches us that improbable events actually do occur sometimes. When the NTSB goes to investigate, the airplane’s black boxes will prove vital in the determination of cause. We can leverage this concept to fortify our chances of surviving a serious investigation. In this article I introduce design considerations for what I call the Black Box Data Store, the important data you need to prove your innocence in an investigation.

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.

By now, I’m sure you’ve heard about the Hudson River landing of US Airways flight 1549. What a remarkable story of an unbelievably low probability risk event actually occurring, and a heroic contingent effort that mitigated a potential disaster. The popular theory on causation is that a flock of birds flew into both engines, causing them both to fail. But how do we know for sure that’s what happened?

When the dust settles, I’d be really surprised if this wasn’t the case. I’m not trying to pitch a conspiracy theory here. My point is that we won’t know the definitive answer until the NTSB (National Transportation Safety Board) completes its investigation. And fortunately, they’re well prepared. Every airplane is fitted with two “black boxes” at the tail of the plane that records vital information for the investigators: the cockpit voice recorder and the flight data recorder.

Now the Hudson River case may seem obvious, and maybe they have enough ancillary evidence to make a decisive conclusion on the bird theory, however maybe not. In fact, in a lot of cases the NTSB investigates, these black boxes are all they really have.

These boxes serve a specific purpose; they support NTSB investigations. The NTSB at some point realized that it would be a smart idea to collect a lot of data on every flight of every plane. The large majority of this data is never used. However, in the unlikely event of a water landing (can you tell I’ve had my share of plane trips), or any other unusual (and usually unfortunate) happening, they have the data that they need to determine what happened.

Your company is in the same position when it comes to compliance. The intelligent architect of a compliance program will design a component of the data system that collects data in anticipation of an investigation. If you follow my work, you know that what I’m suggesting is a contingent control for the risk event of an investigation.

In most cases your controls are dealing with an unfavorable risk to an objective. In this case however, the objective itself is the efficient compliance program, and the risk is that you’ll be audited and subsequently investigated.  The effects of the investigation are probably detrimental to the company (i.e. penalties and fines), so to deal with the effect before the risk event occurs, is what I call a contingent control. Assuming your company is doing the right things, lack of data to prove this can kill you in an investigation. So the approach is to be prepared with lots of good data. And in honor of the aviation system just described, the component of the compliance data system that supports this control is what I call the Black Box Data Store.

The Black Box Data Store is simple in concept, but powerful in function. It can connect to any component of your compliance data system, including your source systems, compliance operational data store, compliance enterprise data warehouse, or even your compliance data marts. Think of it as being downstream from your core compliance data system. When designing your Black Box Data Store, keep the following design principles in mind:

Design Principle #1: Assume Your Company Will Be Investigated

Don’t assume that since an investigation is unlikely, you don’t have to put effort into preparing for it. The incident that just happened with US Airways had a probability of less than a million to one. You must approach this with the attitude that you will be investigated, and design the system appropriately.

Design Principle #2: Collect More Data than You Need

I’ve been on several data warehouse analysis sessions, where the user is mandated to provide an exhaustive list of data points that they want brought from the source system to the data warehouse. This may be appropriate for some strategic purposes, but for a compliance data system it’s the wrong approach. More often than not, during an investigation, you will discover the usefulness of data points that never served a purpose prior to the investigation. You definitely want this data available. Trying to pull in data after the fact is always painful and in some cases impossible.

Design Principle #3: Plan for Design Iterations and Mock Investigations

As with most designs, you will not get it right the first time. To think you will is arrogant, and will cost your company dearly. As with the Hudson River landing, you only get one shot to get it right, so you need to practice several times. Assemble a team of coders, designers, experts on the regulation or standard, and auditors. Build the system you think is appropriate, and have a mock investigation. Do a thorough post-mortem and go back to the drawing board. Plan on at least three iterations, and more is better.

Investigations are a good thing when the NTSB is trying to get to the bottom of an airplane crash, but not so good when your company is the one being investigated. You can help your company be prepared for an investigation with a Black Box Data Store. Assume your company will be investigated, collect more data than you need, and conduct as many design iterations and mock investigations it takes to get it right. You probably won’t get to the point where your company is being investigated; however, you’ll be happy you have a Black Box Data Store if you ever do.

...read the article on ToadWorld

One Bad Apple: What happens to Apple if Steve Jobs Leaves?

REPRINT: From the August 2008 issue of Flawless Compliance(tm). I felt it appropriate, based on the news Steve Jobs is making today. Hope you enjoy (again)!

One Bad Apple

Do Apple Shareholders Deserve to See Steve Jobs' Medical Records?

Steve Jobs doesn't feel well, as he has a "common bug." Picture Source

Is the health of a company tied to the health of its leaders?

I believe so.

The New York Times ran an article in late July on Steve Jobs exploring this issue. You have to admit, he didn’t look all that well when they unveiled the new 3g iPhone. Interestingly enough, at a conference call after Apple released earnings, somebody asked about his health. The response from a company executive was, “it’s a private matter.”

Of course the obfuscation surrounding the “none of your business “ response never puts a lot of faith in the mind of the questioner, or anybody else listening. This consequently caused some speculation on the correlation between Jobs’ health and the sudden drop in Apple’s share price following the conference call. Unable to dispute the evidence that Jobs didn’t look too well, Apple further clarified that it was a “common bug.”

I think, as usual, they’re playing spin games.

Apple has a bad track record of disclosure around this issue. About four years ago Jobs had a rare form of pancreatic cancer, and it took nine months for Apple to disclose this to the public. Now they’re saying, “Oh yeah, the cancer thing. No, don’t worry about that, he just has a little cold or something.” How do we know that for sure? And if something serious does happen to Jobs, how will that affect the shareholders?

This brings up both an ethical and compliance issue. The compliance issue is somewhat objective, so we’ll start there. Does Apple have a duty to disclose Jobs’ health condition? According to TheCorporateCounsel.net,

“Under the SEC's rules, companies typically don't have an affirmative duty to disclose unless a Form 8-K is triggered or a periodic report (eg. 10-Q or 10-K) is due (I say "typically" because there are other 'disclose or abstain' circumstances to consider).

On the other hand, the company may have a duty to update if they have an outstanding statement that the CEO's health is sound. Given that an Apple spokesperson said Jobs' gaunt appearance at a recent event was due to a "common bug," there is an argument that the company had a duty to update (or was misleading to begin with).

Okay, but ethically what should be the call here? In my opinion, it fails the “smell test.” It just smells like something is sour in this situation. I have a real problem with the lack of transparency, with answers like “it’s a private matter.”

Under normal circumstances, I would say the health of a company executive ( or anybody for that matter ) is nobody’s business. However, the litmus test I apply is this. If he were to magically disappear tomorrow, never to return, would Apple be able to maintain its current valuation?

Well, aside from what all the spin doctors at Apple say, I just don’t think so. Steve Jobs is the genius behind Apple. His ideas, brought to life, is what originally made Apple, and what has recently saved Apple’s bacon ( alright, now I’m starting to get hungry ). My feeling is this. If the removal of Jobs ( in any way shape or form ) causes the company to lose any amount of value, then the shareholders have a right to know about any indicators that could cause this event to happen.

But that’s a pretty dramatic assertion, right? It’s pretty invasive to be required to disclose the condition of your health, so we wouldn’t want to put these demands on Jobs in such capricious manner. What’s the appropriate way to approach this?

This is what I would advise the board to do.

The most prudent first step is to establish causation. You have to know within a high degree of certainty that if Jobs leaves, Apple will not be able to operate as well. You can do this with what’s called a Design of Experiments. This is a statistical study that can affirm the causation between inputs ( Steve Jobs ) and outputs ( company performance ).

Once causation is established, the ethical responsibility is clear, and you should fully disclose any health issues. At the same time, I would strongly advise an immediate effort to control this risk. Having one person responsible for the health of a company the size of Apple is irresponsible. The preventive control would be to do anything possible to keep Jobs alive, and the contingent control would be to organize an effective executive team that can operate even in Jobs’ absence.I would do both. The operative word here is effective. Apple has already made statements to the effect that there’s a succession plan in place, but I wonder how effective that will actually be in the event of Jobs’ untimely exit from the company. To establish effectiveness, you can leverage the control plan that was created during the Design of Experiments project.

I really don’t think Apple will go down this road, unless they give me a call. Nonetheless, let’s hope Apple’s board does the right thing. In the meantime, if you’re an Apple shareholder, I’d be careful the next time Jobs gets a “bug.”

How to Survive a Break Without Breaking the Company

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.

You may have noticed that I recently took a short break from my “Quest for Compliance” blogging duties, to handle some unexpected priorities, but now I’m back and it feels great to plug in again. In my case, it’s pretty easy to jump right back into the swing of things, but sometimes coming back from a break can be quite disruptive. This applies to many situations, including your company’s compliance programs. Fortunately with your support, an unexpected break shouldn’t break your company’s stride. In this article, we’ll explore what you can do aid the cause.

Why Your Company Might “Take a Break” from Compliance

Although unpleasant to deal with, breaks from normal operation are not uncommon for a compliance program. That’s because your company’s compliance policies are created and maintained by your compliance organization, however the activities that keep your company in compliance are largely executed outside of the scope of your compliance program. For instance, if your company sells goods and services to the government, your company should have a program devoted to your government contract maintenance and compliance. However, to stand in good stead when dealing with government auditors, the activities of your sales staff need to be under control.

This puts your company in a position where the rules are coming from one organization, and the duties are executed by another. In a perfect world the alignment of both organizations would be in sync however in the real world the two organizations will have different primary strategic objectives. Your government compliance program’s primary objective is to maintain compliance with your government contract. Your sales organization’s primary objective is to make sales.

What does all this have to do with a break?

Well, assuming your sales department and your compliance department have a good relationship and are in sync with each other, following the proper compliance procedures isn’t a problem. However, let’s say there’s a crisis in the sales organization, and they need to forget everything else and focus purely on what it takes to make a sale. As much as your compliance program doesn’t like it, compliance procedure will go out the window. Your sales force will in effect “take a break” from your compliance policy for a while. There’s no way for your compliance program to formally enforce compliance policy, since the compliance organization doesn’t have formal control over the sales organization.

Okay, Crisis Over but Why Aren’t Things Back to Normal?

So what happens when the sales crisis is over? The sales organization returns to normal operation, following all the appropriate compliance procedures, right? Wrong!

What has happened is that too much time has gone by, and the organization has done a collective loss of information regarding compliance procedure. Why only compliance procedures, and not the rest of the procedures? It goes back to the primary objective of the organization. The sales organization is not motivated by staying in compliance, they’re motivated by making sales.

So how do we get the sales organization back on track? Sure, the compliance organization can reinstitute training, but that’s time consuming and the longer your organization is out of compliance, the greater the risk your company is taking. Wouldn’t it be ideal if your sales organization could snap right back into compliance mode? That’s where you come in.

To pull this off, your data around compliance needs to be extremely organized, and accessible to the sales organization. When I mention your data around compliance, I’m referring to policy, like I described in Policy Data Management in 3 Stages. The trick however, is to prevent compliance information loss, even though the procedures are not being followed through the “break.”

Let’s take the last holiday break as an example, which for some of us lasted two weeks or longer. Without any judgment, some of us made a complete break from any work activity, and some of us sort of monitored what was going on by checking emails or possibly taking some calls. For the people that took an absolute break from work for a week or two, this “back to work” week was either very tough, very unproductive, or both. For the ones that kept in touch with what’s going on, it wasn’t so bad.

Continuity is the Key

The difference is continuity. Those that maintain continuity through a break (which sounds contradictory, but that’s only a frame of perception) have a much easier time jumping right back into normal operating procedure. Your goal is to design a data system that empowers your sales force (or any other organization that is required to follow compliance policy) to maintain continuity through a break.

This is an extension of your mature policy management system. I say mature, because you must be at the point where your policy management system is integrated with your process data system, like the one I described in Automated Process Auditing. Also, it needs to be matured to the point where it’s a preventative control system, and not a corrective or adaptive control system (see Prevention over Intervention for an in depth explanation of the difference). This in effect gives you a policy early warning system.

What you’ve done by creating this type of architecture, is given the sales force the ability to review policy at the time of activity (i.e. process of the sale), even though the policy is not being followed. This will keep the policy and procedures fresh in their minds while they navigate through their crisis. To go a step further, you might consider creating a sort of acknowledgment feature in your transaction processing system, that electronically validates that the policy has been reviewed, and it’s purposely not being followed.

Wait, Something Doesn’t Sound Right!

It might sound a little odd that you’re capturing evidence of purposefully violating policy, however in reality it’s the most responsible thing you can do, given the circumstances. I’m not advocating the willful disregard for policy; I’m assuming your company is in a position where it cannot follow policy, and I’m showing you how to lessen the impact from a compliance continuity standpoint. Your sales force is not following policy anyway, and not acknowledging it is not a defense in an audit or investigation.

Having the policy information display as a constant reminder while transactions are being processed will serve the same effect as the person on break that is checking emails. This process will prevent the inevitable decay of policy information retention that will geometrically progress as time goes on.

Breaks in policy are an unfortunate but sometimes necessary reality in the normal course of business. It’s not a popular statement, but it’s a reality that your organization need to be mature enough to face; even if it’s from a risk management standpoint (meaning we don’t expect it to happen, but if it does …). If your company is fortunate enough to come around to that conclusion, they will need your help to architect a system that minimizes the impact. Start drawing plans for the construction of a policy early warning and acknowledgment system to serve the need you now know is there.

...read the article on ToadWorld

How to Build a Case for your Government Compliance Program

Just published in the Coalition for Government Procurement's monthly newsletter called, "Off the Shelf."

It’s no doubt that a Government sales program is one of the most intelligent decisions a company can make to run a balanced and profitable business. With the upside however, comes the responsibility of running a tight compliance program. As a compliance consultant, one of the biggest mistakes I see companies make is taking unreasonable risks with their government contract. And one of the key reasons why they take these risks is because they do not make a strong enough case -- for themselves and their management -- for the proper investment in their compliance program. In this article, we’ll discuss exactly what you need to consider when building your case for government compliance...

...Read a reprint of the full article (PDF)

FREE Compliance Project Charter Template

Hi All,

I just wrote an article for CEO Refresher entitled, "Want to Cut Costs and Still Be Compliant?" You can access it by clicking here.

In the article, I talk about the importance of creating a compliance project charter, and I offer a freeMS Excel template download which is featured on my homepage now. If you would also like to download the template, feel free to download it here.

Of course, let me know if you have questions about the article or the template, feel free to call or email.

Take care, and have a great new year!

-John

Follow me on Twitter, @johnweathington!

In case you just can't get enough of me, you can now follow me on Twitter! You can locate me on twitter @johnweathington. Or, the next time you visit my blog, you can navigate through the new Twitter widget I put on the right panel.

It's a personal feed, so it's not always focused on compliance, but it's still a lot of fun. True to twitter tradition, expect a LOT of updates.

Hope to see you there!

Flawless Compliance Newsletter - December 2008

The December 2008 issue of Flawless Compliance is available, with the Best of 2008! A look back at the most interesting, practical, and thought-provoking articles of 2008.

... read the December 2008 issue of Flawless Compliance

Flawless Compliance Newsletter - October 2008

The October 2008 issue of Flawless Compliance is available, with Center Stage article, A Healthy Government Compliance Program, 3 Steps for Avoiding Huge Government Penalties. Plus, the Dow has its worst week ever, key tips on finding good consultants in bad times, AIG is in the soup, and how to avoid buying a $200 rock.

... read the October 2008 issue of Flawless Compliance

Control Convergence by Example

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.

There’s a big trend in the industry today around control convergence. In a nutshell, control convergence is an attempt to reduce the number of controls in a system, while still keeping things effectively under control.  If you’ve been following me so far, you have a lot of tools for modeling the different kinds of controls that you might find in your company. So in this article, I wanted to walk you through an example that will not only help cement in some of the concepts discussed previously, but also give you a solid foundation for properly supporting a control convergence effort, from a data systems standpoint.

Meet XYZ Healthcare Company

In our example the global finance manager at XYZ Healthcare Company needs to control their accounts receivable process. Strategically, they need to reduce the accounts receivable collection period from 95 days to less than 45 days. This affects the collection process, in which they can receive payments by either check or credit card.

The old process was to just send an invoice, and wait for the customer to pay sending standard letters at the 30, 60, and 90 day late marks. After some brainstorming, XYZ Healthcare revised its collection policy to look something like this.

• Once the payment term has expired, collectors shall call the customer on a regular basis until payment arrangements have been made.
• For customers who wish to pay by credit card, payments shall be processed immediately over the phone.
• For customers who wish to pay by check, sales reps shall make a customer site visit within 2 days of the agreed payment arrangement, to collect the check.

Organic Compliance Growth

Shortly thereafter, PCI compliance became a concern, so to control the risk that sensitive credit card information will fall into the wrong hands they added the following policy points:

• No credit card data will be recorded in the computer systems by the collectors. The collector records all necessary payment information on a special form, which is then passed to a credit card terminal operator for processing.
• Once credit card payments are confirmed in the credit card terminal, credit card forms shall be passed to a supervisor, who shall shred the forms.

Then, the HIPPA ( privacy ) police came along, and noticed that to validate the customer on the phone the collectors were using customer files which contained sensitive data that could be mishandled. So, to control the risk that personal customer data (i.e. social security numbers) will fall into the wrong hands, the following policy point was added:

• At the beginning of each day, the collector shall receive a list of all the customers they will be collecting on, with sensitive customer data for validation. At the end of each day, the collector shall surrender the collection list to the supervisor, who shall shred the collection sheet.

Finally, in the last SOX audit this process was tagged again for control remediation. So, to control the risk that inexperienced collectors will record inaccurate receipts, the following policy points were added:

• The credit card receipts recorded by the collectors shall be reconciled to the amounts processed by the credit card processor.
• The check receipts recorded by the collectors shall be reconciled to the checks collected by the sales reps and further reconciled to the amounts deposited by the supervisor.

And, to control the risk that fraud will occur with checks that are received, the following policy point was added:

• A separation of duties shall be enforced, such that the person collecting the checks is not the same person depositing the checks.

Control Convergence Team to the Rescue

At this point XYZ Healthcare has installed 6 different controls on the same process to cover 4 different compliance concerns ( of course, this is an simplified example – in the real world there could be hundreds of controls around this process at this point). This is okay, but the ongoing cost of compliance is directly related to the number of controls that need to be tested, so they chartered a project team to converge controls, and you’ve been recruited to support the effort from a data systems standpoint.

Converging Controls: Step 1 – Build a Testing Harness

The team will be anxious at this point to jump straight into building a solution. It’s a natural human tendency. You may even see some areas where you could immediately improve their situation by leveraging technology. You and your team must resist this urge, and first fortify your process with a testing system.

Determine the metrics that are important to this process; both from a strategic and compliance perspective. Here what I came up with:

• Collection Period –after all, this is the strategic metric that we’re trying to reduce
• Collection Forms Not Shredded – PCI control violation
• Customer Collection Lists Not Shredded – HIPPA control violation
• Failed Reconciliations – SOX control violation
• Separation of Duties Violations – SOX control violation
• Number of Controls – Your team is making progress if this number is going down

First and foremost, you need to build a data system that will collect and store this data. Then, baseline your current process to see where you are today. If you don’t baseline today, you won’t know if you’re improving anything.

Converging Controls: Step 2 – Make Sure You Can Undo

You need to build a safety net before the innovation process happens. If your “improvement” effort actually causes you to go backwards ( based on your collected metrics ), then you need to make sure you can at least get back to where you were before. From a data systems point of view, think seriously about such issues as a version control system, and a configuration management system. Do a brainstorm – if you had to get back to the old version, how would you do it? From a policy and process point of view, help your business users by building a repository where this can all be stored, with strong change data capture architecture in place.

Converging Controls: Step 3 – Make an Improvement

Now, and only now, start thinking about ways to converge the controls. Here are the ideas I came up with:

• Create a combined credit card / personal information form for processing which can be shredded all at once.
• Automate the reconciliation pieces. This not only reduces the number of controls to test ( two reconciliations can be tested as one reconciliation process ), but it increases reliability and reduces personnel workload.
• Install a policy that only supervisors can deposit checks. Since supervisors cannot be sales reps and vice versa, there is a built in separation of duties control. Now create a daily supervisor assessment form which records amounts deposited, and forms shredded. Between the automated reconciliation and this daily practice, only one control test should be needed that ensures that the assessment process is being executed properly.

Converging Controls: Step 4 – Test the Improvement

Now before you declare victory, gather your metrics again using the testing harness you created in step 1. We know for sure that control points have been reduced from 6 to 3. That’s a pretty good start! But, what happened to the other metrics? Did any control violations increase? If so, you need to undo ( Step 2 ), and try again ( Step 3 ). And what about the collection period? Did it actually increase as a result of your “improvement?” If so, back to the drawing board!

Let’s hope however that your efforts were not in vain. Even if everything else stayed the same, the fact that your controls are cut it half is a reason to declare victory. And if you’re seeing even lower control violations and a shorter collection period – pop open the champagne, you did real good!

...read the article on ToadWorld