Capability Maturity Model and Risk Register Integration: The Right Approach to Enterprise Governance

Author: Luigi Sbriz, CISM, CRISC, CDPSE, ISO/IEC 27001:2022 LA, ITIL V4, NIST CSF, UNI 11697:2017 DPO
Date Published: 24 February 2022
Related: Risk IT Practitioner Guide, 2nd Edition | Print | English
italiano

The total number of active controls in an enterprise is always extremely high. Part of the normal functioning of any process or activity is to define an objective, map the rules to achieve it, put them into practice and then constantly check their alignment with the defined objective. Any control, whatever it may be, represents part of the enterprise’s knowledge, and that knowledge must be reported to the appropriate business owners so they can make informed decisions based on facts and create value for the enterprise.

The main value of a control system is to make the objective-risk-control bond understandable to top management, ensuring timely and accurate assessments to improve the effectiveness of decisions. It is possible to achieve this using pragmatic and simple methodologies and tools that support the established operating model, possibly reusing parts of existing processes in the organization, and increasing the collaboration between them.

Controls and Organization

The controls are not all the same type. They can be specific to a machine, a production process, a person’s performance, a financial transaction, customer satisfaction, the exposure of confidential data, product characteristics and physical security. Some have numerical results, and others have qualitative results; some are applicable with regularity, and others apply only to a specific event; some are reliable, and others must be carefully verified.

Controls can be divided into two categories:

  1. Organizational controls—High-level controls formally linked to enterprise objectives and dedicated to process checks. These controls are aimed at management and are shared with all interested parties
  2. Operational controls—Controls that monitor the performance of a specific activity. These are used by the operators and have no value outside the proprietary process.

For example, verification of the payment of each invoice is operational, and the monthly indicator of the total overdue amount payable is organizational.

The importance of selecting which controls to include in the set of organizational controls, which forms the basis of the internal control function, should not be underestimated.

The only controls of interest to the internal control function are those relevant to enterprise objectives; therefore, some of those controls are considered organizational. Operational controls are not less important, but their results have already been summarized in organizational controls, and, due to their number and specificity, they cannot be easily interpreted by senior management. Based on this subdivision, it is possible to focus on a smaller set of controls that is more manageable.

Proper communication of the results of organizational control assessments to senior management is a fundamental part of the internal control function. For communication to be effective and reliable, it is important to simplify any complexity in the control’s description and to schematically assign the relevant responsibilities to facilitate an understanding of the control itself. It is also possible to condense in a single organizational control all the results of the operational controls that are homogeneous. For example, the organizational control of invoice verification condenses all the verification controls of each invoice issued or received into a single element. A single invoice is not directly related to business objectives, but the total turnover and methods of composition certainly are. The aggregation of many operational controls into a single organizational control reduces the amount of detail, but it increases the ability to create an overview of the process’s operation, which helps management identify any anomalies.

In the relevant management systems, every single event must be controlled to guarantee its authorization and correctness. However, the number of controls in a system is not worrisome because they are automatic. They do not require any effort on the part of personnel because of the availability of software tools that simulate human activity, such as computer-assisted audit techniques (CAATs),1 robotic process automation (RPA)2 and artificial intelligence (AI) bots.3 In practical terms, this software performs one or more of the following functions:

  • Correlating data between different systems
  • Extracting data from one system and transforming them into metadata for another
  • Inserting alerts based on comparisons of different systems
  • Searching for specific combinations of data
  • Accessing information on the Internet
  • Repeating sequences of manual commands
  • Preparing summaries based on assigned criteria
  • Distributing the results according to preestablished workflows

These are just some of the functions, but they illustrate the enormous potential of using automated software tools to carry out repetitive, complex, error- free tasks that are generally considered unrewarding by human operators.

Link Between Risk Factors and Controls

The importance of selecting which controls to include in the set of organizational controls, which forms the basis of the internal control function, should not be underestimated. The controls of interest are the same ones included in the risk register because, when combined with business objectives and identified through risk analysis, they are risk-based controls.4 There is a clear link among threats, controls and risk (figure 1), which derives directly from the definitions of these concepts.

Organizational controls are analogous to those used by the Capability Maturity Model (CMM),5 although with different granularity, to prepare the map of enterprise vulnerabilities because, by definition, the CMM consists of controls relevant to enterprise objectives.6 There is a strong link between the CMM and the risk register, even when considering two different organizational processes: internal control and risk management. From an organizational point of view, they have the same connection with enterprise objectives. Controls are linked through the assessment of performance, while risk factors are linked by the assessment of the likelihood of failing to achieve the objective.

The risk register is the tool to ensure that all identified risk scenarios are taken into account and incorporated into the risk profile at the organizational level. Each risk scenario comprises a record that describes and evaluates that scenario as a function of an event that creates the risk conditions; the asset to be protected, whether tangible or intangible; and all the risk factors that characterize the risk scenario, described through a strengths, weaknesses, opportunities and threats (SWOT) analysis (figure 2).7 It is possible to emphasize the most critical risk factors by using symbols.

In this scenario, all the measures implemented to deal with the risk are represented. The set of containment measures consists of actions or activities already implemented (current controls) and activities planned for the future (countermeasures). In general, this set of containment measures is referred to by the generic term control, without distinguishing the level of implementation of each measure. These controls arise as a response to a risk analysis; therefore, it is accurate to say that organizational control is established in the risk register.

The risk register is the tool to ensure that all identified risk scenarios are taken into account and incorporated into the risk profile at the organizational level.

Risk factors regarding the implementation or effectiveness of the control can be graphically represented with icons, symbols or colors. By aggregating the entries on the registry by risk, asset or control, it facilitates the understanding of the relationships between each risk or between the risk and the controls while providing attention to those that need necessary corrections. The presence of the asset (value for the organization) on each line (which represents a risk) helps to understand the actual risk value, which serves to increase confidence in risk treatment efficacy.

The Control Management System

The CMM is used to assess the ability to complete an assigned task. This ability is called maturity; its opposite, vulnerability, is a synonym for risk. The CMM is represented by a list of all the macroactivities at the organizational level that are relevant to achieving objectives. The evaluation of macroactivities is an organizational control, preferably of the qualitative type, to judge the applicability of the measure to which it refers. In general, the evaluation process is manual (figure 3), but the use of RPA technology is recommended for system-level controls whenever possible.

The need to make a decision about the composition of the checklist does not arise in this maturity model. It is just a collection of all the actions, rules, procedures and processes that have been defined for the smooth running of the business. The controls in the CMM cover all business processes; then, the level of maturity reached becomes the map to follow to make high- level decisions. Because maturity has an inverse relationship to vulnerability, which is synonymous with risk, there is a parallel with the risk register.

To increase the accuracy of the control maturity assessment, the frequency of model updates must be increased.

Current controls and countermeasures are defined in the risk register and represent the controls that must be included in the CMM checklist. To ensure consistency between the two sets, a formal link must be established between the two environments. Their respective uses are different, as is their granularity, but there is a many-to-one relationship between the risk register and the CMM. A control included in the CMM has a higher level of synthesis than that in the risk register, as it does not describe an activity in detail but operates at an aggregate level of category or group to improve the ability to read the phenomenon and highlight only what is significant. For example, in the purchasing area, the risk register contains a control for updating the signature-level definition procedure and another for updating the supplier quality procedure. At the CMM level, there is only a single control that establishes a procedure for updating all internal procedures related to purchases on an annual basis. The meaning is similar, but the risk register provides details about the activity to be done, while the CMM establishes a rule to be respected. The latter allows a more concise and, therefore, more focused compaction of controls.

How to Create the Control-Risk Link

Creating a control-risk link can be quite simple and effective. Suppose a new countermeasure must be added to the risk register. One way to do so is to create the new control and then try to define the links with the CMM, but this is not practical. It is better to choose the control from the CMM list and then customize it by changing its description. This method has advantages because it automatically creates a link during insertion of the countermeasure in a robust (automatic) and transparent way for the user. All attributes defined in the CMM control are immediately transferred to the one in the risk register. At this point, the new countermeasure begins its life as an activity implemented in response to an assessed risk level. It will be enriched with additional attributes, such as the assignment of responsibility and the evaluation of its performance. Some of these data are collected periodically by the CMM automatically and, with an appropriate consolidation algorithm, attributed to the maturity assessment parameters. In the event that a CMM control is updated automatically, manual updating is blocked to avoid the possibility of error (and unnecessary activity).

With automation mechanisms, it is possible to reduce the work of updating the CMM. Given the number of CMM controls (at least a few hundred) and the need to update them periodically for each entity identified in the enterprise, the savings can be substantial. All these controls combined with those in the risk register, including those that can be updated through RPA, constitute, on average, a good proportion of the total controls. To increase the accuracy of the control maturity assessment, the frequency of model updates must be increased. Reducing the number of controls needing manual updates allows a faster iteration of maturity assessment.

How to Adapt the Risk Register to an Enterprise

An enterprise can be divided into several separate organizations, each with decision-making autonomy and a different sensitivity toward the risk profile defined at the central level. Thus, it seems logical to create specific risk registers to reflect each area’s needs. Although the risk register is unique at the enterprise level, it can be adapted to meet the needs of different operational functions using the same approach as the CMM.8

For simplicity, assume that an enterprise is made up of several entities dealing in different types of products. At the enterprise level, headquarters owns a single list of risk factors and a single maturity model that it shares with its entities. At the entity level, the situation is similar, but with fewer risk factors and operational controls; however, the difference is that the entities cannot act autonomously and introduce new controls or new risk factors. The entities must receive these lists, risk areas and controls from headquarters. If an entity sees the need, it can adapt the descriptions to improve local understanding. The link between corporate and entity risk factors and controls is a one-to-many relationship, based on the details they want to manage.

This implies the need to define a consolidation algorithm for the entire enterprise. There are various possibilities, but it is a matter of choosing between a weighted average and the worst choice at each aggregation step. Computationally, determining the worst choice is simple and fast, so consolidating on the fly is always possible, although it involves a certain pessimism and fear for the future. Using a weighted average is more realistic, but it may require some batch updating of aggregations in large enterprises because computation time can be significant.

Having integrated the processes of the CMM and the risk register—both their structures and the link between the corporation and its entities—there is a coherent flow of control information among all the enterprise governance processes (figure 4). Therefore, all enterprise processes will implicitly be risk based, owing to the bond between controls and risk factors. It might seem that a duplicate input of data is needed to configure and evaluate the controls in the two tools, but that is not the case. At the enterprise level, everything is automatically aggregated, even if it is possible to insert high-level risk factors without input from the entities, such as managing nonoperational risk situations or simulations, the results of which are not intended to be shared.

At the entity level, the assessment of both controls and risk factors is included. Logically, the assessment of local risk factors in the risk register takes place first. Here, the controls are assessed as part of the risk analysis, but they are derived, as elements of master data and appropriately customized, from the CMM checklist. After this evaluation, again at the entity level, they are automatically aggregated to generate an evaluation of the corresponding control categories in the CMM. Therefore, direct modification is inhibited in the data entry of the CMM, and only controls that are not derived from the risk register (and not automatic) are assessed manually. This method avoids the unnecessary duplication of data. Furthermore, the latest evaluation is always present in the data entry and can be confirmed with a single click, minimizing the manual updating effort.

By analyzing the overall risk scenario of the enterprise, based on business objectives, new categories or new risk events can be identified, which will subsequently be detailed in the risk register.

The updated sequence of the master data structure for controls and risk starts first with adding controls that are considered relevant to the enterprise to the CMM. The aggregate control can also be understood as a category of control, given its expected level of synthesis. As noted, the control is an activity carried out as a result of a rule, procedure, policy, law, standard or customer requirement, but it is always important for the achievement of the objectives. The internal control function can also propose new controls for its processes; for example, after standard certification audits, the audit report’s suggestions can be extracted and adapted to identify new controls for the maturity model.

Then, following the risk analysis performed by matching the risk scenario with the key performance indicators (KPIs) of current controls, the risk level is deemed acceptable or not; if it is not acceptable, it must be treated with countermeasures. This is done by choosing the controls from the maturity model, permanently preserving the link and then customizing them to adequately adhere to the desired countermeasures. The countermeasure generated is the risk treatment control, which remains linked to the maturity model through the code owned by the control of the original maturity model. This bond allows the automatic information exchange interface between the two structures to remain active.

By analyzing the overall risk scenario of the enterprise, based on business objectives, new categories or new risk events can be identified, which will subsequently be detailed in the risk register. In the same context, those categories or risk events that are no longer relevant must be eliminated to keep the dimensions of the lists of risk factors and controls manageable and easy to use. The risk register is also the tool for defining the relevant assets, risk factors and controls on which to evaluate performance. In practice, manual assessments of the process and risk owners are collected in the risk register, and the maturity assessments of their controls are collected in the CMM. A pipeline from the management systems retrieves all the information suitable for automatic evaluation, which, when possible, is preferable.

Presentation of the Results

The CMM aggregates process maturity information that allows the creation of vulnerability maps for high- level presentations. It is also linked to the enterprise risk report, and this connection makes it possible to create dashboards based on various perspectives. The risk categories can be detailed by risk event; the same is true for macrocontrols in operational controls. At the same time, enterprise information can be investigated by examining a single entity, comparing different entities or even analyzing different time periods.

In general, risk management or control tools do not need to maintain a long history. They are essentially predictive tools used to forecast future trends. To do this, it is sufficient to save the quarterly images for no more than four quarters. In the database, each image is obtained by copying the current data in appropriate columns of the same table. In this way, all quarterly images are always online, making queries simpler and more efficient. For example, with a single query, a representation of the risk can be created; it can even be enriched with graphics to visualize the trend without performance losses.

The solid integration between control and risk data—that is, between the CMM and the risk register— enables every decision-making process to operate according to risk-based logic. The ability to act in the operational area, with information linked to and validated at the level of the enterprise objective, is an advantage for enterprise governance. If the dashboard of risk factors and controls, with appropriate filters, is made available to all operational processes, it can improve communication between the processes and create an awareness of the value of one’s actions with respect to business objectives. Furthermore, it can improve the ability to react to problems.

The solid integration between control and risk data—that is, between the CMM and the risk register—enables every decision-making process to operate according to risk-based logic.

Level of Trust

The ability to make a decision and execute it quickly is closely linked to the level of trust placed in the information received. A robust mechanism for validating the information collected from control and risk processes can facilitate this trust. The internal audit function ensures trust in management systems but does not always have the ability to follow the continuous evolution of business processes.9 An annual plan that is not adapted to address important events cannot guarantee that assessments of the control system are comprehensive, which is necessary to create the climate of trust required to make informed decisions.

To facilitate the audit process, it is necessary to distinguish among different types of audits, balancing the depth of analysis and the level of independence. Instead of a single type of audit of all internal processes, the interventions can be divided into five distinct audit grades (figure 5).

With each increasing audit level, a higher level of trust is achieved; however, given the deeper analysis and the use of more resources, the audit speed will be slower. The five audit grades include:

  • Grade 0 audit—This review of enterprise systems is performed entirely by automatic tools, as a replica of equivalent human verifications. This type of audit is capable of processing very large amounts of data continuously, accurately and without prejudice. Intervention of the software occurs on the entire audit perimeter. Human audit guarantees the integrity and quality of the work performed by these tools, verifying their configurations and operations.
  • Grade 1 audit—This review is performed by entity management, covering the entire control perimeter and implemented in self-assessment mode. The frequency of updating assessments is linked to the occurrence of significant change, but it should never exceed six months. The ideal repository for these activities is the CMM, as it is structured by the entity and contains the complete checklist, with a good summary of the salient facts.
  • Grade 2 audit—This review is performed at headquarters or at the process management level, covering the control perimeter and implemented remotely. The audit frequency is linked to assessment of the risk analysis of the relevant processes, or an audit is triggered if the average maturity value of the processes in question differs significantly from that detected in the entity. The CMM is equipped with overwriting functions of entity-level assessments by management staff.
  • Grade 3 audit—This review is performed by audit process or risk monitoring staff, covering a preestablished control perimeter during the audit definition phase and implemented directly at the entity’s location. The audit frequency is linked to the risk analysis of the entire checklist, for both high-risk assessments and those deviating from average values. This audit level is managed in the CMM, making it possible to modify the assessments of the two previous audit grades. The audit techniques consist of interviews and observation, and any evidence is produced directly by the entity being audited.
  • Grade 4 audit—This review is performed at the auditor level, internal or external, covering a preestablished control perimeter (e.g., purchasing process, IT security) during the definition phase of the audit and carried out directly at the entity’s location. The audit frequency is linked to the risk analysis of the entire checklist, for both high-risk assessments and those deviating from average values. This audit level is managed in the CMM and allows modification of the three previous audit grades. All audit techniques can be used, and evidence is produced directly by the auditors or, if strictly under the auditors’ control, by the entity’s staff.
The advantage for the CMM is assurance that the maturity assessments correspond to reality.

The audit process is based mainly on the results of control assessments. According to a preestablished frequency, all controls are assessed by means of process managers’ self-assessment. Then, based on an analysis of this assessment, iterations continue from risk to risk, with an ever-increasing depth of verification but also fewer checks verified. This compromise—accepting self-assessments for low- or average-risk categories but checking others in a targeted manner and involving subjects other than internal audit staff for operational support—is justified by the guiding principles of the ITIL10 and the Agile methodology.11 By carrying out several iterations, the result is refined at each cycle but at a much lower cost than that of performing a single traditional audit of the entire business and control perimeter.

The audit plan is guided by risk assessments, and the audit ensures the effectiveness of controls. The advantage for the CMM is assurance that the maturity assessments correspond to reality. It may seem complicated to maintain alignment among controls, risk factors and audit tests, but, in practice, it is simple. Between the CMM controls and the risk in the risk register, there is a relationship that can be managed by a data entry form. Similarly, between CMM controls and audit tests, there is a similar relationship with an appropriate modification form for their management. Based on the risk and on these relationships, the issuance of an audit plan can be an automatic process, a true risk-based internal audit.

Conclusion

The world of enterprise governance has always paid great attention to its ability to monitor the performance of internal processes and, at the same time, its ability to guarantee the necessary trust in the indicators collected to make informed decisions. Therefore, it needs to rely on a reference model that can ensure the traceability of the assessment construction process (transparency), the sharing of results with all interested parties (collaboration), the timely recognition of changes in the business (update) and the conciseness of information (effective communication) while maintaining an appropriate cost of operation (sustainability).

The solution that meets all these conditions is the use of the CMM integrated with the risk register at the enterprise level. This bond between the controls of each process and the risk factors identified allows the synthesis of information for management, so that the value of the control and the enterprise context of the risk scenario is clear. Communication of this to management cogently can lead to the approval of effective countermeasures. Maintenance of the control checklist and of the risk factors and their assessments is a cycle that improves with each iteration. The CMM manages controls and, through collaboration with the internal audit function, guarantees the correctness of their assessments, while the risk register defines and assesses risk. The internal audit function also derives its own benefit, as it can be organized in an agile and effective way.

The CMM, the risk register and the audit plan share the same database, which guarantees consistency of data while allowing adaptation of the data structure and reporting with simplicity and speed. In this mode, all processes can realistically be defined as risk based because, through the controls, they are integrated with the maturity model and the risk register. These interconnections guarantee an effective communication process for the prompt identification of vulnerabilities and, consequently, the ability to react and improve the monitoring of risk containment activities.

The enterprise governance design must be adapted to define the clear organizational positioning of the risk register and the maturity model. This change is not only organizational but also operational. Adopting automation software that emulates human control behavior requires greater internal skills, but this upgrade is fully rewarded by the increased number of controls and the improvement in quality. If fear of change is based only on costs that are not well understood, a cost-benefit analysis is necessary to justify such change.

Maintenance of the control checklist and of the risk factors and their assessments is a cycle that improves with each iteration.

Endnotes

1 Chartered Institute of Internal Auditors, “Computer Assisted Audit Techniques (CAATs),” 2020, https://www.iia.org.uk/resources/delivering-internal-audit/computer-assisted-audit-techniques-caats/
2 ISACA®, Implementing Robotic Process Automation (RPA), USA, 2020, https://www.isaca.org/bookstore/bookstore-wht_papers-digital/whprpa
3 Symeonides, M.; “Virtual Agent vs. AI Bot: What’s the Difference?” Axios Blog, 26 January 2021, https://info.axiossystems.com/blog/virtual-agent-vs-ai-bot
4 ISACA®, CRISC Review Manual, 6th Edition, USA, 2015, https://www.isaca.org/resources
5 CMMI Institute, https://cmmiinstitute.com/
6 Sbriz, L.; “Enterprise Risk Monitoring Methodology, Part 4,” ISACA® Journal, vol. 3, 2020, https://www.isaca.org/archives
7 Sbriz, L.; “Enterprise Risk Monitoring Methodology, Part 1,” ISACA Journal, vol. 2, 2019, https://www.isaca.org/archives
8 Sbriz, L.; “Enterprise Risk Monitoring Methodology, Part 2,” ISACA Journal, vol. 2, 2019, https://www.isaca.org/archives
9 Sbriz, L.; “Enterprise Risk Monitoring Methodology, Part 3,” ISACA Journal, vol. 6, 2019, https://www.isaca.org/archives
10 Symeonides, M.; “The Seven Guiding Principles of ITIL 4,” Axios Blog, 2 January 2020, https://info.axiossystems.com/blog/the-7-guiding-principles-of-itil-4-0
11 Manifesto for Agile Software Development, “Principles Behind the Agile Manifesto,” https://agilemanifesto.org/principles.html

LUIGI SBRIZ | CISM, CRISC, CDPSE, ISO/IEC 27001 L A, ITIL V4, NIST CSF, UNI 11697:2017 DPO

Has been the risk monitoring manager at a multinational automotive organization for more than seven years. Previously, he was responsible for information and communications operations and resources in the Asia and Pacific Countries (APAC) region (China, Japan and Malaysia) and was the worldwide chief information security officer for more than seven years. He developed an original methodology for internal risk monitoring, integrating operational risk analysis, assessment of the maturity level of controls and a risk-based internal audit. He also designed a cybermonitoring tool and an integrated system of risk monitoring, maturity modeling and internal auditing. Sbriz was a consultant for business intelligence systems for several years. He can be contacted on LinkedIn at https://it.linkedin.com/in/luigisbriz or at http://sbriz.tel.