SAP

Should we first optimize our security design or implement GRC? This is a common question that I come across while discussing with many of my customers. Why is this such a common question? What is the need to optimize the security design? Why can't we take the existing security design as a starting point and implement GRC? These are some of the questions that follow up the customer question. However anyone familiar with the way security design has been architected in the past will easily identify the need for answering the customer's question as that is the foundation of any compliance framework. Traditionally, security has been used as a tool to get the users to use the system by providing necessary (most of the times excess access). The focus has always been on using it as a technical option to grant access to the system. It was never perceived as a powerful tool in the hands of administrators or auditors for safeguarding the information assets. However with a overwhelming number of regulations and their regulations placing enormous thrust on safeguarding the information systems, organizations can not overlook access controls which forms the basis of any compliance framework. GRC is a powerful tool which can provide detective and preventive control mechanism to monitor access controls. It can help diagnose the SOD report (detective controls) and enable granting access to the system after adequate reviews are done(preventive control). However GRC is only a front end and the real benefit of implementing GRC can be reaped if and only if the back end system is cleaned. Security optimization aims to clean up the existing security architecture by critically analyzing the existing security design for relevance, redundancy, duplication and compliance. There is no one best approach / sequence for security optimization and GRC implementation. It will be good to initiate both the activities in parallel. However depending on the extent of clean up required, either of the two activities could follow up on the other.