How to successfully automate GRC systems in 7 steps

7 phases of planning and implementing GRC automation

As with any major IT initiative, before beginning, obtain approval and funding from senior management. This will likely require preparing a business case and justification for the GRC initiative.

Staffing is the next important element. When preplanning, a GRC automation team, or internal planning team, must be formed. It is also important to check with the IT team to ensure the resources are available to support the introduction of a new GRC system. Whether cloud-based and remotely managed or implemented on-site, make sure the system can be supported by IT.

From here on out, consider using the software development lifecycle (SDLC) to plan and implement automated GRC. The following list highlights each phase in the SDLC and details the steps taken during each phase.

1. Planning phase

Gather information to define the criteria for automating GRC activities. Interview current GRC analysts to understand how GRC is currently performed, and then identify the desired state for GRC management. Also, interview members of the IT team who are currently using data provided by existing GRC activities. Identify the additional information each person requires, as that will be used to define the specifications for the new or updated GRC system.

2. Analysis phase

Once the base data about GRC activities has been identified, this phase examines the issues associated with achieving the level of GRC performance needed by the organization. These requirements become the design criteria for the GRC system.

For established or new GRC programs, a system designed to support GRC functions can be a strategic investment. Look for systems that can capture and analyze a broad range of controls and metrics and then display them on an easy-to-understand dashboard. Report generation may also be important, especially when presenting findings and recommended activities to senior management.

3. Design phase

If the organization is building its own GRC software, this phase is particularly important because the criteria previously defined will govern the GRC system's design, platform, inputs and outputs, UI and other guidelines. If selecting a commercially available GRC automation tool is the likely outcome, the design criteria can be part of the request for proposal or request for quotation. Additional design considerations include system management, maintenance and performance monitoring.

4. Build phase

This phase launches once the design criteria have been agreed upon, a project team has been selected and a project plan has been developed. Again, if this is a homegrown initiative, programmers and analysts will be needed, and their availability must be factored into the overall project timeline. Processing facilities must be scheduled -- unless a separate R&D department with its own infrastructure is available -- and many other activities, such as testing time, need to be anticipated. None of these steps is necessary if an off-the-shelf GRC product is being considered, but companies can use this this time to further examine the selected product, in advance of testing and deployment, to identify any possible issues.

Pre-launch activities also include the following:

• ensuring all ancillary assets -- servers, storage, power supplies, data backup -- are configured and in place;
• ensuring all existing GRC-related files are in place and in the proper data format for use in the system;
• coordinating with the change management team;
• coordinating with the information security (infosec) team;
• ensuring documentation is available for both hosted and on-site installations;
• coordinating with the database administration team;
• ensuring space is available for any on-site hardware;
• reviewing network connectivity, e.g., internet bandwidth, for hosted systems;
• scheduling pre-launch meetings with internal teams and vendors; and
• briefing management on the system's progress and status.

5. Testing phase

Completing system acceptance testing prior to going into production is possibly the most important phase. This is where the new system -- whether homegrown or commercially purchased -- is examined in a near-production mode to determine how things work -- and don't work.

Typical activities include the following:

• running live data sessions;
• finding out how the system handles user access;
• examining how data is managed; and
• testing the system's security features to see if additional protection is needed.

6. Deployment phase

Just before testing is completed and the system is ready for rollout, companies should train primary users, make the necessary announcements, and brief IT leadership and senior company management. Prepare a deployment schedule, and follow it carefully. IT resource management is important here, as it ensures the IT infrastructure is ready for the new GRC application. Deployment can be in phases, perhaps making the system initially available to regular users and then to all others. It is also a good idea to ask users for their feedback on the system after they have used it for a few days.

Post-launch activities also include the following:

• coordinating system changes and modification that are needed based on cutover and system acceptance testing results;
• coordinating data backup and disaster recovery activities with vendor(s);
• coordinating security activities with vendors and infosec teams;
• scheduling and completing training activities;
• sending out notifications to all employees on the new system;
• distributing documentation -- electronic and hard-copy -- to system administrators and users;
• completing a post-installation review and providing results to senior management;
• establishing a maintenance schedule with change management and help desk teams; and
• advising internal audit upon system completion and placement into service.

7. Maintenance phase

After the new GRC system is in production, management and maintenance modes should follow. Initiate metrics to measure performance, set patching schedules and make changes using the company's existing change management process. Once performance metrics, such as KPIs, have been established, schedule periodic reviews with the systems administrator(s) to ensure compliance with the metrics.

Managing and monitoring GRC automation

Once the system has gone live, primary users will manage and monitor it. Assign analysts and/or engineers in the IT department to deal with any problems that may occur. The internal help desk team must be part of the system's development, testing and deployment, as it will be the first to receive any service alerts. Most automated GRC systems will be equipped with tools to perform daily management and to monitor system performance. Be sure the system can generate performance reports that can be reviewed by management.