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