Risk Management Specialization

The job of an IT Administrator has greatly changed over the years.  I have talked about how when I started in IT, the network admin did it all. We managed the servers, workstations, switches, and most of the applications, but over the years it was recognized that some separation of disciplines was needed.  We have all heard the old saying, “Jack of all trades, master of none.”  This is very true, especially in today’s IT environment.  I want my network person to be great at networks; I really don’t care if he knows any Windows stuff, outside of how to make the network talk to it.  The same is true of my systems, applications, and virtualization people – I want them to do what they do well and leave the other stuff to the people who do it well.

Risk management is one of those specialties that is still hovering in the gray area.  We all know it is important, that it is a huge job, but somehow it is often still being pushed off onto the admin, engineer, or project manager.  As an administrator and later an engineer, I am more concerned with the technical issues of a project or system; I may have a vague idea of the risk, legal issues, and policies associated with what I was working on, but I could never claim to be an expert.  Risk can be very hard to predict, especially on very complex systems with lots of users and dependencies.  Risk Management professionals have developed several strategies to deal with assessing risk that they can use to determine actual risk and not just the guesses of an admin, engineer, or project manager.

http://www.zurichna.com/internet/zna/SiteCollectionDocuments/en/media/inthenews/strategiesformanaginginformationsecurityrisks.pdf

I really don’t believe that it is the admin’s, engineer’s, or project manager’s place to determine the risk, cost of the risk occurrence, and cost of mitigation to a project, product, or system.  Should all these people – as SMEs – have input?  You bet.  But as an admin, I really never concerned myself with the cost of a risk or mitigation… just that it was bad if something went down, and that more people would complain if system “A” went down than system “B.”  A Risk Management professional working with management should set those priorities, because what may be important to me as an admin or engineer may not be as important to the company overall.

http://www.sans.edu/research/leadership-laboratory/article/risk-assessment

It seems counterproductive that we would think nothing of bringing in a vendor or outsourcing a new application deployment or major project, but we try to handle something as complex as Risk Management in-house.  It may be that we don’t want to air our dirty laundry, but once again, let trained and dedicated people do what they do well.  Ever heard the phrase, “A fresh pair of eyes?” Same idea here:  look at it in-house and then let an objective outsider take a look and see what you missed.

http://outsourcemagazine.co.uk/using-outsourcing-to-address-risk-management/

We have already seen IT security and project management become a specialty, along with more dedicated IT security professional and project management positions being created.  I believe it is only a matter of time before risk management follows suit.  As we become more connected, and increasingly IT reliant, a dedicated position to handle the complexities of risk management and how it interacts with IT security and project management will have to become the standard.  Just as when it was decided that a network admin shouldn’t or couldn’t handle everything, we will need to determine the same of the project managers, engineers, and admins tasked with risk management as a side duty.