Written by Sean Murphy, Vice President and Chief Information Security Officer, Premera.
Misguided…uninformed…cynical…maybe. Brilliant…accurate…shared by you?…could be! In any case, I thought I’d share in case anyone else has had similar experiences. I would be happy to compare notes and lessons learned.
My organization is going on a journey. We are implementing the HITRUST framework (CSF). Over the course of the last several months, I have been asked, “WHY?” The question comes from my own risk management team. It comes from our internal auditors. I get it from the control owners. But most recently, I got it from my Board. And when I say, they ask me “WHY?” the truth is, the question really is, “This seems too hard. Why are we doing this?”
If you are reading this, I suspect you have access to the HITRUST published answers to “Why HITRUST?” I will spare you a rehash of that. Here are MY answers. There are 3.
- HITRUST provides a roadmap for ensuring the positive changes last beyond personalities. Implementation standards make it difficult to deviate. And once the documents are in place, the procedures are operating effectively, and the control owners are continually improving, it is hard to go back. And as new people enter the organization, the right way to do the job is in doctrine. Other standards or frameworks do not demonstrate the same roadmap.
- HITRUST certification means something. There are two types of people. Those who get certified and those who argue how meaningless it is. And yet, we have gobs of security professionals with the entire alphabet after their name. Even as certification (personal or organizational) does not equal competence or security, it does equal a commitment to improvement, investment, and intentional professionalism. The by-product is better information security maturity, both personally and organizationally.
- HITRUST isn’t any more onerous than any other standard – if you do the other standard right. I encounter so many organizations who implement other frameworks. The insider information is that they scope the controls in such a way as to invalidate the benefit of the framework. “I only scope these systems,” or “I only use the risk management framework categories, not the entire body of controls.” Not pointing fingers, but if one implements the entire control framework and implementation specifications in common tools like ISO27001 / 270002 and NIST (ref: SP 800-53 and SP 800-53A)…I submit the effort would be pretty onerous too, if done right.
Actually, as I guide my organization toward HITRUST CSF implementation and certification, the HITRUST CSF isn’t all that onerous. I’ll save that commentary for another day. However, once you get folks to pick up the shovel and break ground…the most common response is, “Hey, we do most of this already. This isn’t too bad.”
OK, so I don’t phrase my reasons for HITRUST quite the same way for Executive Leadership and the Board. If you are interested in the politically correct version of the rationale to “Why HITRUST?” send me a note. firstname.lastname@example.org
So, onward and upward we go.