Not too long ago, I blogged about “Compliance Lessons from Lance.” And now, there seems to be dramatic evidence of a massive program to fool the compliance system. For example:
Team doctors would “provide false declarations of medical need” to use cortisone, a steroid. When Armstrong had a positive corticosteroid test during the 1999 Tour de France, he and team officials had a doctor back-date a prescription for cortisone cream for treating a saddle sore. (CNN)
The agency didn’t say that Armstrong ever failed one of those tests, only that his former teammates testified as to how they beat tests or avoided the test administrators altogether. Several riders also said team officials seemed to know when random drug tests were coming, the report said. (CNN)
Apparently, this Lance and doping thing is a richer vein than I was expecting.
Reading about how Lance and his team managed the compliance process reminds me of what I hear from some CSOs about how they manage compliance processes.
In both cases, there’s an aggressive effort to manage the information made available, and to ensure that the picture that the compliance folks can paint is at worst “corrections are already underway.”
Serious violations are not something to be addressed, but a part of an us-vs-them team formation. Management supports or drives a frame that puts compliance in conflict with the business goals.
But we have compliance processes to ensure that sport is fair, or that the business is operating with some set of meaningful controls. The folks who impose the business compliance regime are (generally) not looking to drive make-work. (The folks doing the audit may well be motivated to make work, especially if that additional work is billable.)
When it comes out that the compliance framework is being managed this aggressively, people look at it askew.
In information security, we can learn an important lesson from Lance. We need to design compliance systems that align with business goals, if those are winning a race or winning customers. We need compliance systems that are reasonable, efficient, and administered well. The best way to do that is to understand which controls really impact outcomes.
For example, Gene Kim has shown that that three controls out of the 63
in COBIT are key, predicting nearly 60% of IT security, compliance, operational
and project performance. That research which benchmarked over 1300 organizations is now more than 5 years
old, but the findings (and the standard) remains unchanged.
If we can’t get to reality-checking our standards, perhaps drug testing them would make sense.