In my previous position at a database security vendor, I was often asked by marketing to explain the applicability of technology to problems: how you could use assessment for PCI compliance, or why database activity monitoring was applicable to privacy laws, for example.Invariably, the papers I wrote mirrored what every vendor does: create a logical explanation of how bits and parts of the security product addresses compliance challenges. But however logical, this misses the real-world issue of motivation.

A given security widget may genuinely address a regulation. It may even be the best method to meet compliance, but that is irrelevant if the customer does not view compliance as mandatory. Why would they spend money on a product to address a problem they don't acknowledge?

It is for these reasons that I make fun of myself when reading my older white papers, as I now ridicule all vendor justification papers: The grand philosophical arguments are trumped by business realities.

I got to thinking about this when the Massachusetts data privacy standard 201 CMR 17.00 was put into effect in March. Every vendor rolled out its perspective on how it addresses the "challenges" of this new regulatory requirement. Customer questions about the importance of this regulation -- how they might comply with the law, and how they estimate what they are willing to pay for solutions -- are still very much up in the air.

I use Sarbanes-Oxley as an example to illustrate what I mean. In 2005, I learned directly from a dozen Fortune 500 CEOs that they had no intention of complying with SOX: They would first wait to see whether the law would be repealed. If it was not repealed, then they would wait to see whether the regulation was going to be enforced. If it was enforced, then they'd weigh the fines versus the additional auditing costs. Would it be cheaper to legally challenge the law? They would re-evaluate two years down the road, and if they found they needed to comply, then they would throw up their hands, say "mea culpa," and provide their remediation plans.

There were layers of business risk analysis that occurred long before they dug into understanding and reporting financial accounting risks. HIPAA was no different. I am betting Massachusetts data privacy standard 201 CMR 17.00 falls into the same category of "wait and see."

Companies will wait for a while before starting a compliance program. Once a business conducts the evaluation of its security risks to sensitive data, it's somewhat compelled to act if it finds something bad. It's one thing to claim you were not sure if there was a risk or did not think the law applied to you. But it looks really bad in court, after a breach has occurred, if you were aware of the risks and did nothing. So the mindset is that it is best to remain ignorant altogether.

The logical part of my brain loves that the Massachusetts privacy law tasks companies with understanding their data security risks. Risk is something they understand. The regulation specified that you will build a security plan around challenges specific to your organization's risk, looking at both the data and systems that manage data. There is no encryption loophole for companies to excuse sloppy security. They will have a tough time blaming data theft on product vendors if they select the wrong product or scapegoat IT if they do not respond to discovered risks. I think this law makes meaningful advancements in data security requirements, and I like to think that companies that make money from personal information should have some custodial responsibilities to the safety and security of other people's information.

So I was thinking, "Great, I'll write a justification piece for database security." In practice, social security numbers, driver's license numbers, passwords, and other personal information are being stored in relational databases. 201 CMR 17.00, HIPAA, and many of the regulations don't call out database security specifically, but relational databases are the primary storage management system for this data. My intention when starting this blog post was to outline a plan to understand risk, and outline how auditing, assessment, DAM, encryption, access controls, and application programming can be applied to meet different threat types. I may still do that, but the question remains whether companies will actually take action to understand the risks. Is this law actually a business driver?

If you want to see a security program outline for meeting Massachusetts data privacy standard 201 CMR 17.00, then I would be happy to post here on the blog. (Let me know via the "Comments" box below).

But I think a discussion about whether this law will be taken seriously needs to happen before we decide how to comply.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.