Roadblocks of Traditional Maturity Model

By Pravin Kothari  |  Posted 2010-09-13 Print this article Print

Roadblocks of traditional maturity model

Now that advanced automation technologies are on the market, and many of the early adopters of GRC technologies have advanced to the final phase, many users are finding that the maturity model is wrong because the work they have done in process design and process automation cannot be leveraged in the final automation phase. They found out that, all this time, they have been designing and building a car-but a car will never be able to take them to the moon.

For example, several organizations followed this path in the last three to five years. They diligently worked out their process, then bought some GRC products to automate their process, and finally even implemented limited control automation with success. As they started to scale, they ran into a brick wall and had to start over with new processes and new technologies. Here are three conclusions they found:

Conclusion No. 1: Processes are not automation-ready

When the processes were designed strictly to be manual processes (using tools such as spreadsheets and e-mail messages), they often broke when full automation was introduced. When manual tasks are automated, people's roles in the process can fundamentally change. For example, a manual process may require an application administrator to run monthly scans, review the scan results, answer an assessment and then attach the scan results as evidence. In an automated process (where the scans are done daily or weekly), the administrator is only alerted when exceptions are found, so the process is less a periodic procedure one and more an event-driven, continuous one.

Conclusion No. 2: Processes do not go far enough or become redundant

When processes are designed without automation in mind, they become bound by what is only achievable by humans. These processes don't go far enough for two main reasons. One is a lack of resources and another is an addition of processes to compensate for what cannot be done. For example, a manual risk assessment process may require that 25 percent of applications be assessed for every assessment period, followed by an extrapolation process to see how the data sample can help estimate the risk for the whole applications population. If automation can enable 100 percent assessment, then the sampling process needs to change and the extrapolation exercise becomes redundant.

Pravin Kothari is founder and Chief Technology Officer at Agiliance. Pravin is responsible for product vision, product strategy and engineering at Agiliance. Pravin has over 20 years of success at bringing new products to market in information security, compliance, enterprise software, software as a service, and large-scale software infrastructure. Prior to founding Agiliance, Pravin was the founding vice president of engineering at ArcSight, where he led the product development for five years from inception to market dominance. Prior to ArcSight, Pravin was the founding chief architect at Impresse Corporation. Previously, Pravin held technical leadership positions at Verity, Attachmate, and Tata Consultancy Services. Pravin holds a Master's degree in Computer Science from the Indian Institute of Technology (IIT), Bombay. He is a Certified Information Systems Auditor (CISA), a Certified Information Systems Security Professional (CISSP) and Charter Member of TiE, a global organization dedicated to the advancement of entrepreneurship. He can be reached at

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel