Last week I spoke with a firm to discuss compliance strategy for data privacy protection of personally identifiable information (PII). A number of state laws were potentially in play, including Massachusetts 201 CMR 17. We discussed what applications and databases were in use, how information moved, and some specific in-house issues. Then I discussed the different technology options for each platform that were available, mentioning which threats the products addressed and the relative cost of implementation and maintenance.

Even over the phone, I could hear heads spinning on the other side of the line. Too. Much. Information. And far too complex for them to come away with any coherent strategy or action plan. Forget running -- we needed to get to a crawl. It was clear the firm did not have the time, manpower, or budget to go through the full analysis process. And even if it did, it would have ended up with a half-dozen separate and distinct projects, each with its own learning curve, each with a different product to obtain, and each with a different skill for management.

That's where I simply cut to the chase: I advised a single technology, in two specific implementations, that provided basic security across all of the platforms for all of the use cases.

Why? Because it was going to address most of the issues the company had -- it was not even fully aware of the issues it needed to address -- and it was within its capability to implement. I hate to do this because sometimes it feels like compliance for the sake of compliance. Personally, I like to pick tools and technologies that best fit my category of need, be it compliance, security, or whatever. That said, sometimes best of breed is not possible. Selecting "the best" technical solutions app by app creates project and operational complexity that would simply never work in this case.

I've talked a lot on this -- here and on the Securosis blog -- about how complexity makes it harder to do security. Certainly guys like Bruce Schneier and Dan Geer have covered this in great detail as well. Examples I've witnessed firsthand, such as security settings being difficult to check, made it more likely people will make a mistake or skip the process entirely. If code is hard to read, then code reviews are less effective. Complexity makes things hard to understand and, in turn, results in less effective security -- in this case, complexity from an implementation and management perspective. Getting 90 percent of the way home was better then outright failure.

Does this sound cliche? Sure, it does. Do companies still bite off more than they can chew? Absolutely. The person who wants the work done is a specialist and wants things done to his or her standards, often beyond IT's capabilities. It's a reality for many IT organizations that the best choice is often the simplest to implement, or the simplest to use.

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