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.