Agile GEIT Practitioners Guide, Part 1

Ever-increasing legal and regulatory requirements have an impact on Agile’s ability to respond to customers’ needs in a timely, effective and efficient manner. To limit that impact and maximize value delivery to the organization, a governance of enterprise IT (GEIT) system focused on managing IT risk within the Agile environment is required. A GEIT system enables the enterprise to take full advantage of IT, maximizing benefits, capitalizing on opportunities and gaining competitive advantage. ¹ Fundamentally, GEIT is concerned with 2 separate but related components: first, the managing of IT-related risk and second, IT value delivery to the business. ²

The managing IT risk component requires building an internal control system to protect and control the Agile development process and build 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 so its compliance and control assurance evidence generation have minimal impact upon Agile’s responsiveness to market requirements.

These components go hand in hand and cannot be dealt with separately or, worse still, bolted onto the Agile development process as an afterthought. They need to be included in a structured approach in which decisions are well informed, aimed at meeting clearly defined stakeholder requirements and guided by frameworks that adhere to the information security standards.

This Agile-GEIT (A-GEIT) implementation guide provides a phased approach to implementing such a GEIT system. A-GEIT consists of 6 phases. Each of the phases and related tasks provide guidelines on how the task may be performed in the Agile context and, in most cases, is followed by a control implementation (e.g., Jira Jenkins and Github “service, infrastructure and applications” enablers).

This guide suggests that by placing each phase and task in the Agile context and supporting it with a simple implementation example, this will assist the practitioner in gaining an understanding of the Agile development process that can be applied to solving more complex security requirements inherent in information systems.

This installment is the second of a 3-part series of articles on the topic of how Agile governance can be used to build trust to maximize value delivery. The 3-part series is complemented by an overview that was published as an online exclusive article as part the ISACA Journal, volume 6, 2018. The overview introduced the A-GEIT concept and the 6 phases of the A-GEIT implementation guide.

This installment (the first of the 2 parts of the Practitioner’s Guide) describes the first 3 phases of the A-GEIT implementation guide. It describes the process, tips and tools for building the information enabler critical to the successful implementation of the GEIT system, and the internal control system to manage Agile’s IT risk. The second installment of the Practitioner’s Guide describes the last 3 phases of the A-GEIT implementation. It describes the process of using the information enabler in a planned compliance and control assurance effort to design the internal control system into the Agile process. The focus of this phase is to ensure that control compliance and its assurance evidence generation has minimum impact on Agile’s responsiveness to market conditions.

Figure 1 lists the overview and 2 installments of this practical guidance, followed by their roles in describing the 6 phases of the A-GEIT implementation.

Figure 1—The 6 Phases of A-GEIT Implementation

The overview article describes and details:

• Agile’s inherently fluid environment created by its values and principals and its supporting software tool set
• Agile’s security, compliance, assurance and agility stakeholder requirements and how these requirements seemingly contradict each other
• The challenges Agile’s fluidity and contradictory stakeholder requirements present to Agile’s governance
• Examples of how these challenges manifest themselves in the day-to-day Agile development process

Together, the overview, first and second parts of this series of articles provide guidance that outlines a phased approach, overlaid by 3 distinct IT risk/value delivery efforts, to lead practitioners in planning and implementing an A-GEIT system that both accommodates Agile’s fluidity and meets its contradictory stakeholder requirements to find the balance between managing Agile’s IT risk factors and maximizing its value delivery. This guidance is not meant to be a magic solution, but rather a guide for practitioners in using and adapting COBIT 5 enablers to the unique set of Agile’s governance challenges.

Phase 1—Determine Current State

This phase supports the informed decision-making effort. Again, this effort builds on the information enabler critical to the successful implementation of the GEIT system and is based on the very simple principle that the more the IT risk team understands about the organization’s Agile implementation, the more informed its decisions will be regarding designing risk mitigation (i.e., controls) into the process.

The objective of this phase is to gain a detailed understanding of the organization’s specific Agile implementation. There are several tasks to be performed to achieve this objective. Those tasks include:

• Develop and document best practice-focused interview questions.
• Document the Agile practices and existing or potential controls.
• Perform an analysis of the Agile practice as implemented by the organization to determine the compliance and control assurance effort required to realize the full business benefit of Agile.

Develop and Document Best Practice-Focused Interview Questions
For this task, the IT risk team utilizes COBIT 5 best practice descriptions to develop a set of interview questions used in team interview sessions to help define all the Agile practices that make up the Agile development process. These questions are designed to give structure to and streamline the IT risk team’s interview sessions with Agile developers and testers.

The Agile development process consists of a number of Agile practices strung together to represent the organization-specific implementation of the Agile development process. In the context of this series, examples of Agile practices are:

• Sprint planning
• Development
• Peer reviews
• Pre-release testing
• Post-release testing

Each Agile practice has, in turn, a set of organization specific characteristics that represent how the Agile practice is implemented. Examples used herein include “resources required to perform the Agile practice” and “supporting software.”

To obtain an accurate and detailed record of the Agile practice and its implementation information, the interviewer needs an understanding of the Agile methodologies’ values and principles, knowledge of the multitude of software components used to support the Agile process, and an awareness of the challenges of defining GEIT system within this environment.

It is a daunting task for the interviewer to inquire after all these moving parts looking for existing controls and auditable control assurance evidence. It would be easy for the interviewer to miss some critical elements. To simplify the interview process, interview questions are used to focus on the best practices as defined in COBIT 5.

The benefit of using interview questions based on best practices is that it is easier to first identify an Agile team's best practice area and then use the interview questions to drill down into the Agile moving parts looking for existing controls or potential controls that may be shaped into complete controls by generating control assurance evidence for them.

Here, the IT risk team looks at the COBIT 5 processes and their best practices and translates the COBIT 5 best practice statements into a set of open-ended questions to draw out factual information, rather than yes-or-no responses. The interview questions are designed with equal focus on defining each of the Agile practices and related outputs, and how the outputs are produced ( figure 2).

Figure 2—Best Practice Interview Questions

Once the interview questions have been completed, the IT risk team can proceed to conduct the interviews.

Document the Agile Practices and Existing or Potential Controls
This task goes beyond identifying existing and potential controls within the organization’s Agile processes and builds the information enabler used to inform control implementation decisions.

To define a potential control, the definition of an internal control should be reviewed. An internal control is an exciting policy, procedure or practice that provides reasonable assurance that business objectives will be achieved. In contrast, a potential control is an exciting policy, procedure or practice that lacks the control assurance evidence to provide reasonable assurance. Potential controls represent the cases where the control is enforced, but the control assurance evidence is not stored and published centrally.

In this task, the IT risk team interviews the Agile development teams to identify each of the Agile practices making up the organization’s Agile development process, and any existing or potential controls within the Agile practices. Figure‭ ‬3‭ shows how the IT risk team may record the‭ “‬Peer review‭” ‬Agile practice.‬‬‬‬‬‬‬‬‬‬‬‬

Figure 3—Sample Agile Practice—Peer Review

Comparing these Agile practices and controls side-by-side provides the IT risk team with a good understanding of how the Agile development process is being implemented within the organization and serves as a vital source of information in the phases that follow, in which the IT risk team designs the controls into the Agile process.

During the interview process, the interviewer listens for an Agile process best practice response such as pre-release testing, then refers to the best practice question set asking questions such as:

• Who writes and executes the test?
• How are the tests performed?
• Where are the testing results stored?
• Who independently reviews the test results?

These questions allow the interviewer to probe interviewees for information about the process practice and its outputs.

During the interview, in addition to recording Agile practices, the team also records how the Agile practices are implemented within the organization.

Perform Analysis to Determine the Compliance and Control Assurance Effort Required to Realize the Full Benefit of Agile
In this task, the IT risk team records information on how the each of the Agile practices is implemented within the organization and records implementation information such as “resources required to perform the Agile practice” and “supporting software.”

This task provides a structured location in which to hold this implementation information and will be used in later phases to enable the IT risk team to make informed decisions regarding designing the controls into the Agile process. Figure‭ ‬4‭‬‬ shows how the IT risk team may document the implementation information for the‭ “‬Peer review‭” ‬Agile practice.‬‬‬‬‬‬‬‬‬‬

Figure 4—Agile Practice—Implementation Information

This implementation information storage is based on the very simple principle that the more information the IT risk team has, the better its decisions.

This structured store is to be extended to include any piece of information specific to the Agile practice the IT risk team deems relevant and may help its decision-making regarding control implementation.

During the interview sessions, the interviewee records this information and correlates it to Agile practice. Once this task has been completed, the IT risk team should have a good understanding of the organization’s specific Agile development process implementation and can now proceed to the next phase.

Phase 2—Determine Target State

This phase supports managing IT risk to the “build trust” effort. Again, 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.

The objective of this phase is to define an internal control system to protect and control the Agile development process and support the effort to build trust by guiding the IT risk team through the tasks of defining the goals, scope and the internal control system. This phase also supports, in part, the informed decision-making effort.

Along with the set of internal controls, the IT risk team also documents the control implementation information that may be used to improve decision-making regarding the design of controls into the Agile development process.

There are several tasks to be performed to achieve this objective. Those tasks include:

• Define the scope and goals of the target state.
• Identify the target state internal controls.
• Record the control implementation requirements.

Define the Scope and Goals of the Target State
This is a two-step task of:

1. Defining the goals
2. Defining the scope of the internal control system

Define the Goals
In this task, the IT risk team uses COBIT 5’s stakeholder goals mapping tool, which lists enterprise and IT-related stakeholders and their goals, to define the goals of the Agile internal control system. This task is of critical importance because it supports the objective of defining a GEIT system that will ensure stakeholder requirements are evaluated to determine agreed goals for the Agile internal control system.

From COBIT 5’s complete list of stakeholders and goals, the IT risk team narrows its focus on the Agile stakeholder requirements of security, compliance, assurance and responsiveness to market. This narrowed focus is specific to this guidance and should be read keeping in mind that this guidance focuses on protecting and controlling the Agile development activities. An organization may have different requirements from its Agile development process and, as such, should utilize COBIT 5’s complete list of stakeholder goals to identify its Agile internal control system goals.

Figure 5 indicates the narrowed focus on COBIT 5’s enterprise and IT-related goals in the left column and, in the right column, Agile’s internal control system goals derived from them. These Agile internal control system goals will drive the creation of the internal control system and will be at the center of all efforts in this guidance.

Figure 5—Stakeholder Goals Mapped to Agile Internal Control System Goals

Source: Adapted from ISACA, COBIT 5 Implementation , USA, 2012

Once the Agile goals have been defined in terms of the enterprise and IT-related requirements, the IT risk team can proceed to defining the scope of the internal control system.

Define the Scope
This task uses COBIT 5’s processes for GEIT mapping to select the processes that touch the Agile development process and can influence achieving the Agile goals set in the previous step. This guidance uses the COBIT 5’s GEIT processes mapping to ensure that there is a complete and reputable source for identifying the organizational processes that touch Agile. Examples of the COBIT 5 processes that touch the Agile development process could include BAI02 Manage Requirements Definition, BAI07 Manage Change Acceptance and Transitioning and DSS04 Manage Continuity. Defining these processes gives guidance to the IT risk team when selecting the controls to manage the IT risk factors at those touchpoints.

Once the target-state goals and scope have been defined and identified in terms of a complete list of organization processes that touch and impact the Agile process, the IT risk team can proceed to defining the internal controls that will be used to manage the IT risk factors at those touchpoints.

Identify the Target-State Internal Controls
The purpose of internal controls is, ultimately, to manage IT risk by protecting and controlling the Agile development activities. The internal controls will be used as the basis from which to generate the trust in Agile’s ability to safeguard its assets.

Agile and its supporting tool kit encompass many different components, these include:

• Agile software development process
• Application source code
• Continuous integration/continuous delivery (CI/CD) release mechanism
• Release environment
• People that operate the development process

To implement a true defense-in-depth strategy, each of these components needs to be protected and controlled with its own custom control system.

This article only discusses the controls that relate to the Agile software development process itself with the aim of controlling all development changes that are dropped into the process and ensuring that information security is an integral part of information systems across the entire life cycle.

Controls for the various components can be selected from a number of control sources such as ITIL, the International Organization for Standardization (ISO), internal security baselines, the Open Web Application Security Project (OWASP), relevant internal policy standards, or legal and regulatory requirements. Not all control sources provided equal control selection guidance; some control sources focus on giving guidance on enterprise-level control selection, others on processes level, and others on application code level. In selecting component controls, practitioners need to carefully consider the control source and at what level it provides guidance.

In this task, the IT risk team uses 3 different control sources from which to select the target state internal controls. These control sources are ISO 27002 Information technology--Security techniques--Code of practice for information security controls, the EU General Data Protection Regulation (GDPR) and a small subset of typical internal information security standards. The target state internal controls are not meant to be a complete list of controls to achieve the protect and control goal, but rather a narrowed set that needs to be enhanced to meet the organization-specific requirements ( figure 6).

Figure 6—Sample Target State Controls

Record the Control-Implementation Requirements
In this task, the IT risk team records information on the human or other organization resources required to implement the control and requirements against each of the selected controls.

The control implementation requirements provide a structured location in which to hold these implementation requirements and will be used in later phases to enable the IT risk team to make informed decisions regarding designing the controls into the Agile process.

As with the Agile practice implementation information mentioned earlier, it is important to gather and store control implementation requirements. These 2 pieces of information will be used in later phases to inform the IT risk teams decisions regarding control implementation and help them better integrate the control into the process.

The example control implementation requirements, shown in figure 7, detail a few requirements and are meant only as an example that needs to be extended to include any piece of information specific to the selected control.

Figure 7—Control Implementation Requirements

After completing the interviews in the previous phase, the IT risk team has a good understanding of the human and software resources used to perform the various Agile practices. The IT risk team then uses this understanding to complete the control implementation requirements and record the organization-specific resources and other requirements that will be required to implement and enforce the controls. After defining the internal control system that will be used to manage IT risk and build trust, the IT risk team proceeds to the gap analysis phase.

Phase 3—Perform Gap Analysis

As with phase 2, this phase also supports managing IT risk to the build trust effort and focuses on further building the internal control system.

The goals of this phase are to identify the existing controls and, potentially, any missing controls by guiding the IT risk team through the tasks of identifying 3 key pieces of information:

• Which controls exist in the Agile development process, along with the appropriate associated control assurance evidence
• Which controls need to be added to the Agile development process
• Which Agile practice outputs may be fashioned into controls by generating appropriate control assurance evidence

The main task in this phase is to compare the current state to the target state identifying met, not met and partially met controls.

For this task, the IT risk team performs a control gap analysis to determine if the controls existing in the Agile process are supported by the appropriate control assurance evidence. These controls are categorized as met. Controls that are required to be added are categorized as not met. Other controls that may already exist but could be adapted to complete a control cycle by generating appropriate control assurance evidence are categorized as partially met. Partially met controls are of particular interest to the team since they indicate a possible opportunity to make small enhancements to either the Agile process or its supporting software to transform the Agile artifacts into a measurable control.

These small enhancements represent the least intrusive way to design a control into the Agile process and are the least likely to impact Agile fluidity. Here the IT risk team records the status of the control against each of the selected internal controls: met, not met or partially met.

Along with the control status, the IT risk team also documents the justification for categorizing the control with a particular status. The justification will be used in later phases to verify the control status ( figure 8).

Figure 8—Gap Analysis

Once the control gap analysis has been completed for each internal control, the IT risk team can proceed to the next phase where it will consider how to design the controls into the Agile process.

The next phase will be described in the second part of this Practitioner’s Guide. It describes the process of using the information enabler discussed herein in a planned compliance and control assurance effort to design the internal control system into the Agile process.

Conclusion

The first 3 phases of the Agile development process—Determine Current State, Determine Target State and Perform Gap Analysis—have been described in this Practitioner’s Guide.

The Determine Current State phase explains the tools and techniques used to build the information enabler detailing how the Agile process is implemented within the organization in terms of the resources and software tools used in its implementation. It introduces the best practice-focused interview questions to streamline the interview process. Also, the Agile practice implementation information tool is used to store the information enabler in a structured format.

The Determine Target State and Perform Gap Analysis phases describe the process of defining the internal control system. These phases identify the Agile stakeholder requirements of security, compliance, assurance and responsiveness to market and define the internal control system to meet those stakeholder requirements.

The next installment of the series will describe the last 3 phases of A-GEIT implementation, which include a planned compliance and control assurance effort using the information enabler as a primary component to design the internal control system into the Agile development process, so that its compliance and control assurance generation has minimal impact on Agile’s responsiveness to market. This is supported by examples of using the processes and service, infrastructure and applications enablers to build and integrate the internal control system.

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

¹ ISACA, COBIT 5 Implementation , USA, 2012
² Ibid.
³ ISACA, Internal Control Using COBIT 5 , USA, 2016
⁴ Op cit COBIT 5 Implementation