Compliance Options: The Power of Rules

by Gwen Thomas
August 1, 2009

When my brother, sister, and I were kids, we loved to play Three Stooges. We’d walk into ladders, carry boards so they’d smack into things, and yell, “Nyuk, Nyuk, Nyuk!” as we twisted each others’ noses and tried to poke out each others’ eyes.

The problem with this game was our mother. If we were indoors when we were playing, the chaos and screams would eventually get her attention. She’d then speak those dreaded three little words: “No roughhousing indoors!”

And that was it for Three Stooges time. We Thomas kids were loud and energetic, but we weren’t stupid. We knew which rules could be broken and which ones couldn’t.

We knew that “no roughhousing indoors” wasn’t a law, like “no stealing.” We knew it wasn’t a community rule, like “don’t leave toys on the sidewalk.” It was a policy—Mama’s policy—and the fact it was arbitrarily enforced wasn’t important. If it mattered enough in the moment for Mama to utter those words, then we knew it was time to pay attention. Something was going on that made the policy important, and it didn’t matter if we were privy to the details. We knew that, for now, compliance wasn’t optional.

Maybe it was those years of dramatic tension between structure and chaos that lured me to the world of data management. On the one hand, we have the beauty of architecture. On the other hand, many practices are still pretty rough-and-tumble. There are those who strive to evolve Three Stooges antics into precisely choreographed dances, but the truth is most IT shops operate somewhere in between. Sure, there are laws and regulations that must be obeyed. There are policies that sometimes seem to be arbitrarily enforced. And then there are those good practices we want to enforce—and the people who shout them down, taking advantage of chaos to slip through bad work, uncontrolled processes, or non-standard data.

Here’s where compliance can be your friend. Compliance requires adherence to a set of conditions; these may be spelled out as regulations, policies, or rules. Rarely will these conditions be specific enough to describe your hour-to-hour activities. Instead, it’s up to you and others to interpret how those conditions map to your processes and practices.

For instance, Sarbanes-Oxley compliance requires formal, consistent, documented, and auditable controls over financial data. These controls were initially spelled out at a very high level, based on universal good practices such as checks and balances. Then they were spelled out in more detail appropriate for different job areas. For financial clerks, it meant the person who entered a vendor’s information into a system wasn’t allowed to issue a check to that vendor. In your arena, there was probably a policy—or at least a departmental rule—constraining activities in development environments vs. production environments. If you (or others) didn’t like that rule, chances are the mantra, “It’s required for SOX compliance” was enough to win the argument for compliance.