Is IRM (Information Risk Management) an overhead? Reduce the Effort- Merge it with CRM (Corporate Risk Management)

Any project has a mandate to do program level risk management, which handles risks like delays, efforts, coding, dependencies, client enviornement and so on. Project appoints security manager becuase ISO 27001 certification is required and he comes up immediately with an additional task- Please perform security risk management and here is the IRM methodology you need to understand and then assess informtion security risks based on same.

Response from project management....Am too tied up with project delierables...don't have time to understand one more methodology...Already doing CRM...Why don't you do it for our project...Take a trainee if required...

Security Manager: Hey...IRM is not an trainees job..we require someone who understand the project...

and the argument goes on....or Security Manager bows down. IRM remains more of a compliance issue rather than a tool to manage real security risks.

ISO 27001:2013 has given us solution to above problem.

In previoius version of ISO27001 i.e. 2005 one , it was expected to perform risk assessment in a pre-defined standard manner- you need to identify assets, identify vulnerability and threats to those assets, find out existing controls and so on. These has to be done in specific order to comply with the security standard.

Come 2013 version of ISO27001 and this requriement is gone. I am not saying risk assessment is not gone. One is still required to do risk assessment and then Risk treatment, however, requirement that a series of actions to be done in a specific order has been lifted.

Which means- Now you may have your own RM methodology.

When this option exist and project is anyways doing CRM, then why to make a different methodology. We should know that all risk management broadly do same tasks- Do risk assessments, vaulation, prioritization and then mitigation. Having IRM merged with CRM,  will certainly makes life of GL and PLs for the project easy, as now operational risks and security risk shall be assessed using same methodology.

Do we require to do some ammendments to CRM methodology- Not really but somewhere you need to relate the tasks to the internal and external issues identified for the project and also you need to introduce a process to attach a risk owner to each security risk, as these are requirements from ISO27001: 2013 standard.

Well having risk owner shall be good for CRM (operational risks) as well, so one improvement suggestion from your side.

Life will certainly be easier for all Risk Assessors.

Views by Naveen Gupta

Rate this article: 
0
No votes yet
Article category: 

Comments

It is a good thought to allign the two. However, the issue that I have with this is that the CRM would be based on the risk appetite of the supplier organisation (in the example that you have in your mind TCS) while the demands and expectation of the client may be at a different level of risk. While the IRM piece may not address this in a holistic manner it will at a minimum provide a focus for the delivery team as to what the client expectation is.
In the above sense I would still see a major benefit of deploying an IRM individual on projects especially ones where the client may have onerous (in security terms) requirements for us to deliver.

IRM is hardly an overhead.  We see failure to consider operational risks cause problems almost daily.  So, here we see one of the ultimate outcomes as a result of focusing IRM and Information Security in I.T.  I agree that corporate risk should be comprehensively managed by the CRO or equivalent.  With regard to risk assessment, I strongly recommend a business model risk assessment as a first step to focus detail level risk assessments.  Boiling the ocean by trying to assess risk associated with each individual asset and working bottom-up is counter-productive.  On the other hand, if you identify a Web portal, for example, as a critical service, then all of the assets supporting that service inherit its criticality.  So, it is not enough to inventory your assets...you also need to understand asset interrelationships and dependencies.

Pages