Ask a new question, get a better answer
By suncpo on Oct 22, 2006
One of the major elements in any comprehensivew piece of privacy legislation is "reasonable" security for the personally identifiable information (PII).
I attended the IAPP (Int'l Association of Privacy Professionals) in Toronto Canada this week. My very brave CISO from Sun came along to do a talk with 2 Deloitte partners and me regarding the relationship between the CPO and the CIO in the protection of PII.
Two things struck me as very interesting. First, Sun's CISO, Mark Connelly, was shocked at how few CPO's have a good working relationship with the key players in IT. Second, the majority of CPO's we met lamented the lack of a good working relationship with IT and an even greater lack of understanding about the tools and technologies that are supposed to be in place to protect data within an organization and its partners/ vendors. (Now, I grant you that I don't have a perfect understanding of the zero's and ones myself, but I \*do\* have Mark and a gang of other really smart folks who help me out at Sun.)
Here's what I think is going on & how I think we, as a privacy community, can make things better. The trouble with a complex and largely horizontal responsibility is that it is easy to turn to your right and ask, "Is the data secure??" (That's the old question.) The new question should be "HOW is the data secured and how will you test/prove that it is secure?"
We ask only \*if\* PII is secure and not \*how\*. This is the critical difference.
I am not suggesting that we, the non-techs, all march back to school in one en masse engineering do over. I am, however, suggesting that we make certain that certain features are on the list of requirements before any IT is purchased, any vendor is selected or any system goes live. We need to ask more and better questions before we are forced to live with bad answers.
For example, Identity management systems are worthless if you can't use them to audit systems-- we need to \*prove\* the chronology of access in case of breach.
Or another example, an operating system should allow us to place different customer data into different containers to keep it separate-- or the defective OS systems that do not have containers should have mitigating features that compensate for their lack of compliant enhansing built-ins.
The \*how\* data is secured architecture is just as important, if not more, than a simple "yeah, data's secure" statement.
If you haven't buddied up with your technical team yet, please do. Be fearless. Get to know a little bit about pocket protectors and maybe Star Trek. You'll be glad that you did and the world's data will be a wee bit more safe and a wee bit more reliable because you did.
Just a thought...