eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Governance, risk management and compliance (GRC) is a very broad discipline consisting of policies, compliance, enterprise risk, operational risk, governance and incidents. There is no such thing as a standard maturity model in terms of which specific function to start with and how to proceed after that.
While it is typical to see the majority of organizations starting with compliance automation, there are instances where organizations begin with risk, policy, incident or threat management. Although inconsistent, there seems to be a commonly accepted maturity model in terms of technology adoption, and its three steps go something like this:
Step No. 1: Start with process
People often say that GRC is all about process, so the design and implementation of processes should come first before even thinking about technology. This includes workflow and procedures, roles and responsibilities, and documentation requirements.
Step No. 2: Follow with process automation
Common wisdom says that once process has been implemented and the kinks have been worked out, then it’s time to implement automation to make those exact processes run more efficiently. Technology people usually start with workflow, collaboration, documentation management and project management. This spurred the growth of first-generation GRC products which replaced spreadsheets and e-mail messages.
Step No. 3: Automate the control by integrating with your environment
Once manual processes have been streamlined and semiautomated, people eventually start to think about maximizing automation by integrating directly with existing applications and security infrastructure to automate data collection and testing of controls. This sets people free from much of the repetitive tasks of data gathering, correlation and testing. This is GRC nirvana. This is where IT GRC technologies enable continuous compliance and real-time risk management.
This sounds like a straightforward and perfectly logical maturity model-so what’s wrong with it? This model came about when there were very little GRC technologies available. The model evolved as the technology evolved.
Roadblocks of Traditional Maturity Model
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.
Process-Only Technologies Cant Scale
Conclusion No. 3: Process-only technologies can’t scale
GRC automation is a generic term. Organizations often do not realize that process automation and control automation are very different and unrelated technologies. Process automation is fairly pedantic. Documents management, workflow and collaboration technologies perform useful functions but, technically, they are not very challenging to build. Process automation products don’t deal with a large amount of data or assets, so performance and scalability are not required.
On the other hand, control automation is seriously advanced technology. Building an engine that can extract and correlate millions of data records every day is hard. Building bidirectional integration to other vendors’ systems that works as expected (under all different scenarios) is hard. Building an engine to manage hundreds of thousands of assets, and to change those assets’ profiles and classifications-and determining what controls are relevant for each asset-is hard.
If a process automation-only product is selected, then the organization will need to start over if they want to implement control automation and reach GRC nirvana. Trying to extend process-only technologies to achieve IT control automation is like strapping homemade rockets to your family sedan. The outcome is not likely to be pretty.
A Better Deployment Maturity Model
A better deployment maturity model
Now that the GRC industry is more mature and there’s a bit of 20/20 hindsight, it’s time to adjust the deployment maturity model to avoid these known pitfalls. The following model, derived from user feedback, is ideal. It’s simpler and lowers project risk. For easy reference, the traditional model just explained will be referred to as the “horizontal maturity model” and the new model about to be explained will be referred to as the “vertical maturity model.”
The vertical maturity model starts with a narrowly defined use case and deploys an end-to-end automated solution for that use case in Phase 1. In other words, all three phases of the horizontal maturity model are tackled all at once but in a smaller scope. Three common approaches in picking a narrow use case are:
Approach No. 1: A single compliance requirement such as the Payment Card Industry Data Security Standard (PCI DSS) or Health Insurance Portability and Accountability Act (HIPAA)
Approach No. 2: A single process such as incident management or vulnerability management
Approach No. 3: A single stack of technologies that make up a critical system
For the selected use case, a fully-automated, closed-loop automation solution with accompanying processes should be designed. The use case should include a combination of process automation and control automation. Once Phase 1 is successful, then the same approach to additional use cases can be replicated. The use cases ought to be narrowly defined, and each use case must achieve “end state” automation within a single phase.
Benefits of Vertical Maturity Model
Benefits of vertical maturity model
This vertical maturity model has the following three benefits:
Benefit No. 1: Demonstrate vision and success quickly
A long-running project timeline is one of the top reasons for IT project failures. By piloting a narrowly defined use case, the project team can show success and vision quickly. By demonstrating to the organization what the automated end state looks like in a miniature scale, it validates the business case and generates excitement for continue investment.
Benefit No. 2: Minimize change management
Change management is often the most difficult part of any new technology adoption project. It takes tremendous time and effort to change how people do things. By achieving the final automated end state in one phase, the project team can avoid repeatedly asking users to change process and adjust to new tools.
Benefit No. 3: Validate technology selection early
By implementing full automation in Phase 1, the project team can fully test out the automation capabilities of the chosen technology platform. If the right technology has been selected, then the project team has reduced the risk of technology failure for future phases. If the wrong technology has been selected, then the project team can still cut its losses and make a change without too much lost investment. In other words, if you want to go to the moon, you better figure out early if you bought a car or a rocket.
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 pkothari@agiliance.com.