Agile GEIT, Building Trust and Maximizing Value Delivery: Part 2 Practitioner’s Guide

To minimize the impact that ever-increasing legal and regulatory requirements have on Agile’s ability to respond effectively and efficiently to customer needs and maximize value delivery in a timely manner require a governance of enterprise IT (GEIT) system equally focused on managing IT risk and the delivery of a value-add outcome to the organization.

Managing the IT risk component requires building an internal control system to enhance the controls over the Agile development process. By doing this it builds trust in its ability to safeguard its assets.

The value delivery component requires a planned compliance and assurance effort to design the internal controls into the Agile process, where its compliance and control assurance generation has minimum impact on its responsiveness to market.

These components are to be integrated in the Agile development process rather than added on as an afterthought. These components must be part of a structured approach that will lead to informed decisions aimed at meeting clearly defined stakeholder requirements and guided by a complete and reputable framework and information security standards.

This is the third installment in a series describing an Agile GEIT (A-GEIT) implementation guide, a phased approach to implementing such a GEIT system. A-GEIT consists of 6 phases ( figure 1). Each of the phases and associated tasks provide guidelines on how the task may be performed in the Agile context and, in most cases, is followed by control implementation examples using JIRA, Jenkins and GitHub “service, infrastructure and applications” enablers. Part 1 of this series described the first 3 phases of A-GEIT implementation:

1. Determine current state
2. Determine target state
3. Perform gap analysis

Figure 1—The 6 Phases of A-GEIT Implementation

Part 1 described the process, tips and tools for building the information enabler critical to the successful implementation of the GEIT system, and it defined the internal control system to manage Agile’s IT risk.

This installment describes the last 3 phases of the A-GEIT implementation guide. It describes the process of using the Information enabler, built in the previous installment, in a planned compliance and control assurance effort to design the internal control system into the Agile process where its compliance and control assurance generation has minimum impact upon Agile’s responsiveness to market. This is followed by examples using the procedure and service, infrastructure and applications enablers to build and integrate the internal control system.

Phase 4—Planned Compliance and Control Assurance Effort

This phase supports value delivery to realize the full business-value effort. To recap, this effort focuses on compliance and assurance in designing the internal control system into the Agile process. The goal of this phase is to plan the internal control system implementation, which supports the full business-value effort by using the COBIT 5 Information enablers collected in previous phases to inform the IT risk team’s decisions on where and how to implement the selected controls that will have minimum impact on Agile’s responsiveness to changes in market conditions.

Phase Goals

• Plan the internal control system implementation.

Phase Tasks

1. Select from the gap analysis controls with “Not Met” and “Partially Met” statuses.
2. Value delivery-based decision making by IT risk management.
3. Document the nontechnical control implementation plan.
4. Define control assurance assertion.

Phase Task 1
For this task, the IT risk team uses the output from the gap analysis phase ( figure 2) to identify which controls need to be implemented in the organization’s Agile development process. The IT risk team validates the control status assigned in the previous phase and determines if the control actually contributes to achieving the goals of the internal control system. Once the list of controls has been verified, the IT risk team can then proceed to the following task of deciding how to implement the controls.

Figure 2—Gap Analysis

Phase Task 2
For this task, the IT risk team, supported by the technical control implementation team, defines a nontechnical control implementation plan for designing controls into Agile’s development process. This plan is the materialization of managing IT risk to build trust and value delivery to realize full business value efforts.

As part of managing IT risk to build trust effort, the IT risk and technical control implementation teams plan how to implement controls to protect and control the Agile development process and the ability to safeguard assets. As part of the effort to deliver value to realize the benefits, the teams design the internal controls into the Agile process where its compliance and control assurance generation has minimal impact on Agile’s responsiveness to changes in market conditions.

The teams plan to control implementation using the information enablers collected in the previous phases (Agile practice—implementation information and the control—implementation requirements).

To demonstrate how these information enablers assist in decision making, one can look at the example listed in figure 3, where the peer review control is designed into the Agile development activities and its control assurance evidence is generated concurrent to the Agile practice.

Figure 3—Agile Practice Peer Review

Considering the Agile practice—Implementation information collected in the Phase 1—Determine Current State, the 2 teams have a detailed understanding of the enterprise resources and tools used to perform the peer review of the Agile practice and can use figure 4 to form the following conclusions:

• The peer reviewer performs a review and sends a Slack instant message to the developer signifying peer review approval.
• This Slack instant message is not stored and centrally published, which means the Agile team has no evidence of peer review approval.
• Because a peer review is performed, but the approval not stored, the peer review control has the status of “Partially met.”
• The Agile practice peer review uses 2 different pieces of software.
• Developer checks code into GitHub.
• Peer reviewer uses GitHub to view development changes and perform the peer review.
• Peer reviewer uses Slack to communicate the approval.

Figure 4—Agile Best Practice Implementation Characteristics

Considering the control selection performed in the Determine Target State phase and displayed in figure 5, the teams understand the need for the peer review control.

Figure 5—Control Implementation Characteristics

Considering the output of the Perform Gap Analysis phase shown in figure 6, the 2 teams have an understanding of the current state of the peer review control. From the justification, the teams understand that to convert this Partially Met control to Met, they need to store and centrally publish its control assurance evidence and consult with the technical implementation team on how this could be achieved.

Figure 6—Gap Analysis

The IT risk and technical control implementation teams may use this information shown in figure 7 to make IT risk management/value delivery-based decisions to design the control into the Agile development process where its compliance and control assurance evidence generation does not impact Agile responsiveness to market conditions.

Figure 7—Technical Control Implementation

The following are justifications of how the control implementation protects Agile's responsiveness to market conditions:

• GitHub’s storage of the peer review approvals circumvents the need to communicate approval via the Slack instant message and removes the need for Slack completely.
• Removing the Slack tool and the extra Instant Message approval step further improves Agile’s fluidity by reducing the number of software components.

This very simple peer review control implementation example illustrates the important part that the Information enabler plays in IT risk management/value delivery decision making. This example of information gathering before decision making may be applied to more complex problems such as extracting testing evidence from the continuous integration/continuous deployment (CI/CD) pipeline to ensure that the appropriate pre- and post-release testing has been completed.

Once the control implementation decisions have been made, the IT risk team can proceed with documenting the decisions and justification.

Phase Task 3
For this task the IT risk team documents the decision and its justification as a nontechnical implementation plan ( figure 8). Here, the IT risk team documents the decision made in the previous task, detailing how the software components or the Agile process needs to be modified to meet the control requirement. The plan and justification will be used in the next phase by the technical control implementation team to guide the control implementation.

Figure 8—Nontechnical Control Implementation Plan

Once the nontechnical implementation plan has been documented, the IT risk team can proceed to defining the control assurance assertion.

Phase Task 4
Referring to figure 9, defining a control assurance assertion allows the control to be monitored and measured. If a control cannot be monitored, evaluated or compared, then it does not actually provide any assurance.

Figure 9—Control Assurance Evidence

This task defines the control assurance assertion, which provides an unambiguous assurance goal for the selected control. An important part of defining the control assurance assertion is to verify that the proposed control assurance evidence is an adequate form of evidence for the assurance function.

Here, the IT risk team must select a sample of the control assurance evidence and present it to the assurance function for evaluation. At this stage, the IT risk team will not have the actual executed control assurance evidence, just the proposed evidence that will be collected; the assurance function will be asked to step out of its typical role of assessing existing evidence into a role of assessing the proposed control assurance evidence in order to verify the evidence validity (i.e., is it acceptable).

Once the nontechnical control implementation plan has been documented and the control assurance evidence verified, the IT risk team may proceed to document the proposed Agile internal control system.

Phase Output: Planned Agile Internal Control System
The output of this phase is a planned Agile internal control system. The Agile internal control system represents all processes that touch the Agile IT risk environment along with the controls selected to manage these risk factors.

Figure 10 represents the Agile development process and its selected information security controls. This simplified view of the Agile internal control system shows the Agile practices making up the Agile development process. The bold text under the Agile practice represents the COBIT 5 processes that touch the Agile practice, and the numbered items represent the selected information security controls.

Figure 10—Agile Development Process

Phase 5—Execute and Establish Process Phases

This phase supports the delivery to realize the business value. It includes 2 separate but related subphases. The first subphase is the Execute Phase, with its goal to “Build the internal control system.” It focuses on designing the internal controls into the Agile process. In this phase, the A-GEIT implementation guide uses the JIRA, Jenkins and GitHub “service, infrastructure and applications” enablers in its examples of how to enforce automatic controls and generate control assurance evidence for them.

The second subphase is the Establish Process Phase, with its goal to “Document a software development life cycle (SDLC) procedure.” It supports this effort by using the “procedure” enabler to enforce manual controls and guide the Agile development team toward compliance to automatic controls.

Phase Goals

• Build the internal control system (Execute).
• Document an SDLC procedure (Establish).
  • Guide developers and testers toward compliance to manual controls.
  • Guide developers and testers on the correct usage of the software tool set to ensure the generation of control assurance evidence contemporaneous to the Agile practice.

Phase Tasks

• Document a technical control implementation plan.
• Build the internal control system.
• Document an SDLC procedure.

Phase Task 1
For this task the technical control implementation team supported by the IT risk team translates the nontechnical implementation plan to a technical plan ( figure 11). This plan is used to guide the technical team in the following task of building the internal control system by enhancing the software tool set to enforce the controls. Each technical control implementation plan has 3 overarching objectives:

1. Record the technical enhancement made to the Agile teams’ software tool set to implement automatic controls.
2. Enable requirements traceability.
3. Ensure control evidence generation contemporaneous to the Agile practice.

Figure 11—Technical Control Implementation Plan

Here, the technical control implementation team, supported by the IT risk team, considers the nontechnical implementation steps documented in the previous phase and adds the technical step to realize the former.

Once the technical control implementation plans have been completed for each of the selected controls, the IT risk team can proceed to the following task of building the internal control system.

Phase Task 2
For this task, the IT risk team prepares an action plan detailing the control measure, owner, critical success factors, key dates and the technical control implementation plan created in the previous task. The action plan is handed to the technical control team for resourcing and implementation. Simultaneous to running the action plan, and upon completion of each of the individual control implementation plans, the IT risk team must complete and document an SDLC procedure ( figure 12).

Figure 12—SDLC Procedure

Phase Task 3
The technical control implementation plan created in the previous task details the implementation of automatic controls and requires the software tool set to be used in a specific way to ensure control compliance and to trigger the software to generate control assurance evidence. In this task, the IT risk team documents the SDLC procedure and the specific way the software tool set must be used. This operational SDLC procedure is to be updated to reflect all new automatic control implementations.

The SDLC procedure is independent of the development methodology. It contains a set of instructions detailing the steps required to comply with manual and automatic controls and the steps required to trigger the software tool set to generate and record control assurance evidence.

The methodology and independent nature of the SDLC procedure create a layer of abstraction, that enables the organization to utilize various development methodologies while standardizing the way the supporting software tool set must be used to meet compliance requirements. The format of the SDLC procedure document combines the contextual detail of a process and the technical detail of a procedure. This combination more closely reflects the Agile team’s interactions and role fluidity and provides an operational context that reveals the role of the software tool set in enabling the end to end Agile process.

The primary purpose of the SDLC procedure is to guide developers and testers toward compliance to selected controls; secondarily, it feeds the MEA02 Monitor, evaluate and assess the system of internal control process by providing a list of mandatory steps required to trigger evidence generation. These steps should be monitored to ensure that the control assurance evidence is being consistently generated for automatic control.

Phase 6—Monitor, Evaluate and Assess the System of Internal Control

This phase supports the managing IT risk to build trust effort. To recap, this effort focuses on building an internal control system to protect and control the Agile development process and build trust in its ability to safeguard its assets.

As such, the phase goal to “plan a monitoring solution to monitor control compliance and ensure consistent control assurance evidence generation” supports this effort by guiding the IT risk team in planning a control monitoring solution and highlighting the Agile anomalies which impact it.

This phase purposely narrows the stakeholders and goals of the monitoring solution to that which serves only the internal control system defined in previous phases. This narrowed focus is to be enhanced to meet the enterprise-specific monitoring solution requirements; but for the purpose of this phase—which is to highlight the Agile anomalies that impact a monitoring solution—this narrowed focus will suffice.

This phase takes the IT risk team through the tasks of defining the monitoring solutions key performance indicators (KPIs) and Agile anomalies to consider when implementing the monitoring solution.

Phase Goals
Plan a monitoring solution to monitor control compliance and ensure consistent control assurance evidence generation.

Phase Tasks

• Define monitoring solution goals.
• Define KPIs.
• Monitor control compliance and assurance evidence within Agile.

Phase Task 1
The first step toward creating a monitoring solution is knowing what is to be achieved. This starts with defining the stakeholders and their goals.

In the context of the internal control system goals, the monitoring solution’s stakeholders have been defined as business, compliance and assurance, and the goal defined as “monitor control compliance and ensure consistent control assurance evidence generation.” This monitoring solution will be used first by the compliance stakeholder to ensure that the Agile development activities are controlled and protected in accordance with internal information security policies and standards, and second, by the assurance stakeholder looking at the control assurance evidence and providing the business with the trust that Agile's assets are being safeguarded.

Once the IT risk team has defined the monitoring solution goals in accordance with the enterprise’s stakeholder requirements, it can proceed with defining the KPI.

Phase Task 2
Here, the IT risk team translates the monitoring solution goals into a specific, measurable, attainable and relevant set of KPIs ( figure 13).

Figure 13—Key Performance Indicators

The KPIs are used to measure how effectively the Agile development teams comply with the control assurance assertions set in a previous phase. As such, the control assurance assertions play a significant role in the definition of the KPIs.

Again, the intention of this task is not to define a complete list of KPIs, but rather to narrow down the list that supports the internal control system. The point to note in this task is that the KPIs should reflect the control assurance assertions and, as such, the example KPIs listed should be seen as nothing more than examples.

Once the objectives and KPIs have been defined, the IT risk team can proceed with defining a monitoring solution to monitor automatic and manual control compliance.

Phase Task 3
For this task the IT risk team considers the KPIs and how to achieve them within Agile’s fluid environment.

Agile’s inherently fluid environment, as mentioned earlier, is created in part by Agile principles and values and in part by its software tool set. This task suggests that Agile principles and its supporting tool set should be considered when planning a control monitoring solution.

An example of the type of Agile anomalies to consider is the impact the Agile principle “accommodate changing requirements throughout the development process” has on the monitoring control compliance.

The change in requirements may be introduced mid-development and has an impact on the associated acceptance criteria. It may possibly outdate the acceptance criteria and impact the protect and control requirement to “use valid and measurable acceptance criteria to test information systems.”

The control monitoring solution validates that the Agile team always has relevant and valid acceptance criteria before beginning to test the Agile practice. Agile's supporting software tool set being so closely linked to control implementation and development activities can facilitate these kinds of subtle compliance monitoring requirements.

Another type of consideration centers around control assurance generation. In the previous phase, the IT risk team defined an SDLC procedure, which detailed how the Agile development team is to use the software tool set to automatically generate control assurance evidence contemporaneous to the Agile practice.

The IT risk team is to consider monitoring compliance to the SDLC procedure steps. Monitoring compliance to these steps will ensure consistent control assurance evidence generation and utilizing the Agile software tool set allows for these types of bespoke assurance evidence monitoring requirements.

The Agile supporting tool set creates its fair share of compliance challenges, but also provides huge opportunities for fine-tune compliance monitoring and, if configured correctly, could provide a real-time compliance monitoring solution notifying the compliance team of any breaks immediately and enabling immediate rectification before the break compounds in severity.

Conclusion

The Agile methodology is defined as a set of principles and values that guide software development teams toward responding to customers' needs in a timely, effective and efficient manner, thereby reducing the business risk of irrelevance.

Today's ever-increasing legal and regulatory requirements place greater burdens on enterprises to manage IT risk and exercise due care in protecting and controlling the Agile development process. This emphasis on IT risk management, along with its accompanying controls and compliance checks, distracts the Agile development team from being responsive to market and impacts the enterprise's ability to maximize Agile value delivery.

To rectify this situation and prevent the downward spiral of Agile value delivery caused by the persistent presence of risk management over Agile processes requires a GEIT system concerned with IT value delivery to the business and the mitigation of IT-related risk.

This A-GEIT implementation guide provides a phased approach to implementing such a GEIT system. The A-GEIT phases and enablers are overlaid by 3 distinct risk/value delivery efforts, namely:

• Gathering information to enable informed decision making
• Managing IT risk to build trust
• Value delivery to realize full business value

These efforts focus the IT risk team’s attention on meeting the stakeholder requirements for and challenges to implementing a GEIT system for the Agile development environment. Planning and building a GEIT system are not onetime efforts but require constant monitoring and improving to meet the ever-expanding legal and regulatory requirements and to accommodate Agile's ever-evolving supporting tool set.

Michael Bergman, CRISC, CISSP

Is a consultant working in the overlap where IT risk meets information security. He has a wealth of experience functioning across the first and second lines, defining and implementing internal control systems. He passionately believes that behind every good control system is an even better implementation plan and execution team.

Endnotes

¹ Slack includes a cloud-based set of proprietary team collaboration tools and services. Slack offers a number of Internet relay chat (IRC)-like features including persistent chat rooms (channels) organized by topic, private groups and direct messaging.