The Challenges of the IT GRC Maturity Curve
Whenever a company embarks upon its journey along the IT GRC maturity curve it will invariably face the same challenges that any other company does.
However, the move from a compliance centric approach to a risk centric approach can be made that much less daunting if this process of evolution is broken down into smaller, more manageable, chunks.
Generally, the appetite for such a change in approach is a move from being driven by External Mandates to one that is driven by the needs of the business. At the lower end of the curve the focus is on passing audits and often utilises manual methodologies i.e. collecting information on spreadsheets, questionnaires or SharePoint. At the higher end the measurement is more focused on performance and risk as part of a continuous improvement.
It’s a path I have trodden myself some years ago when a previous employer moved to a more risk focused approached to IT Security.
The first step at the compliance-centric end is a realisation that it is no longer possible to keep up with regulatory and audit requirements while continuing to use the manual tools at your disposal. These invariably consist of check box driven processes and procedures and gathering the controls manually. The growing number of mandates and the need to increase the frequency of assessments quickly reach a point where that methodology is prone to error and distraction and is no longer viable, efficient or cost effective. There is a need to automate.
Automation of this process will require a new tool set. Things to consider as part of an overall solution may include out of the box regulatory content, platform coverage, ability to absorb procedural controls, risk management capabilities, vulnerability assessment, ability to digest 3rd party data, and finally, scheduled reporting and dashboarding capabilities. Once the product is selected and implemented the first step is to select a suitable out of the box technical standard to measure against and the next stage in the journey is now well underway.
The next challenge to address is Prioritization. Selecting an out of the box technical standard allows you to get up and running and gathering vast quantities of data in a very short space of time but does have its drawbacks. With all the data that is now being collected, effectively and efficiently, there is a need to identify and more importantly, prioritize security issues that need to be fixed to ensure IT resources are being focused on the things that matter the most.
Part of the same challenge is how Information Security communicates the audit findings or remediation requests to IT Ops. There is no point in simply raising a series of never ending Help Desk tickets or issuing a 300 page ‘paperweight’ of a report. This result will leave you still sitting towards the lower end of the maturity curve, albeit slightly further on that when you started but still with no clear view of where your risks and the priorities lie. However, if you use risk to filter and prioritize the actions of the IT Operations team then you are clearly moving towards the top end of the curve.
With this in mind, you should now be looking at building a sustainable program that develops the use of the product that has been procured. It should be one that will allow you to quickly adapt to new regulations, changes in the threat landscape and, importantly, refine the technical standards that are used and consequently the data they collect from the targeted environment. This refinement could take the form of customisation of the out of the box technical standards so they are more in line with the business needs or, alternatively, developing in-house custom technical standard from scratch. The approach that is chosen will generally be governed by the maturity and size of the Company itself. Financial Institutions are a prime example of this. They have developed their own internal policies and technical standards and have employee’s whose prime responsibility is to maintain and develop them. In my last year in such a role, an in-house technical standard was developed using our toolset of choice. It was aligned with the paper-based platform standard and could perform a full Security Acceptance Test on a server and deliver extremely accurate results in less than 20 minutes. If there were more than 15-20 findings in the report then it was fairly certain that the server in question had a) not been built using the Gold Build media or b) settings had been changed after it had been commissioned. This was a huge difference from the 2 days timescale and error prone process that had existed just a few years previously. It was by no means an overnight change but one that had been refined and develop gradually.
By this stage you should be looking to build security into everything you do. Approaching it in a systematic, sustainable way rather than creating one off events, trying to get ahead of the curve and addressing weaknesses proactively. You should also be exploring programs that are able to deal with other aspects such as vendor risk management or find that the toolset already procured has that capability built-in or available in the form of an additional module.
At the top end of the maturity curve you will be able to demonstrate the relevance of security to the broader business. Information Security is no longer silo’ed but is regarded as relevant and engaged with the rest of the organisation. It’s no longer a last minute thought in a project but instead becomes a fundamental playing an advisory role assisting the Business Units invest their money where it make most sense to protect the key and critical assets while also addressing the risk appetite. Depending on the approach taken during the evaluation and procurement process you may find that you already have Risk Management functionality available to you.
It is well worth remembering that this is by no means an overnight transformation but one that can take a number of years to reach maturity. Finally, it should be noted that while many aspire to reach this goal very few organizations do and find instead that they address all the requirements somewhere in the top half of the maturity curve.