Before reading this article on DevOps Audit Program, you may find it easier to understand if you read the articles below first.

- Link1: http://tokenterrace.com/eng/197

- Link2: http://tokenterrace.com/eng/198

The DevOps Audit Program is a framework that helps you perform IT audits in a DevOps environment.

# Differences from COBIT 5's 4 management processes 

(CPBOT 5 also includes EDM (Evaluate, Direct, Monitor), which covers the governance process, but I'm including it in the following because it's what I'm talking about)

I'm going to cover the 4 management processes in COBIT 5 and how they differ from each other as I understand them. What I've written below is by no means a complete description of the 4 management processes, but I think it's enough to give you a good idea of how they are structured in your work.

1) (APO) Align, Plan and Organize: 

Strategic alignment of business goals and risk management, strategic management, etc. 

This domain is about ensuring that the organization's business objectives and risk management strategy are aligned. To elaborate further, IT systems are ultimately aimed at achieving whatever goals the organization has set, based on priorities and risk management methods. IIT policy or strategy. Architecture, etc. should be defined so that you can assess whether they are aligned with the business strategy and enable the IT organization to deliver value, and IT auditors should review the organization's risk management strategy and assess the effectiveness of the controls in place to mitigate identified risks. 

So what are the differences in DevOps?

The DevOps Audit Program includes requirements related to an understanding of Agile methodologies and organizational culture. This is where I mentioned the need to understand cultural differences in my previous post. Understanding the DevOps environment should be a top priority in order to design a control scope that is different from traditional IT audit methodologies. For example, in the DevOps Audit Program, controls related to organizational culture include understanding how the requirements management process differs from the controls for requirements updates, and how communication is done in CI and CD for customer satisfaction in a DevOps culture.

I covered these in a previous post as well : )

2) (BAI) Build, Acquire and Implement: 

Program/Project Management, Requirements Management, Change Management, Compliance, etc.

In this domain, you should be able to evaluate whether requirements, etc. are properly designed to meet the company's objectives and managed processes, such as change management, are applied to meet the company's risk management strategy in relation to IT programs/projects. On a more practical level, ensuring that the entire process of implementation, acquisition, and execution is consistent with the company's risk management strategy means being able to assess whether the project was truly initiated out of necessity and can be completed within the expected timeframe and with the expected quality.

The DevOps Audit Program covers the iterative and collaborative development process from an Agile methodology perspective. Continuous deployment and iterative feedback is what it's all about, and you should be able to understand and evaluate the change management process to see how the process works from initial deployment to receiving feedback and then deploying again.

3) (DSS) Deliver, Service and Support: 

Business process related controls and continuity management, operations management, problem management, service support, etc.

In this domain, we are looking at how the service is managed and the processes for incidents, problems, etc. You need to be able to see the processes in place to ensure that the quality of IT services is managed to the customer's desired level and assess the timeliness to ensure that incidents or problems are acted upon in a timely manner. In DevOps, changes are more frequent, so there are aspects of the domain that are more emphasized in terms of ensuring the integrity and security of the system. You should be able to understand how automation and infrastructure management impacts test, staging, and production servers in the process of reliable and repeatable deployments.

When reviewing the change management process, you should evaluate whether the controls in place to manage change, including code review, testing, and approvals, are effective.

4) (MEA) Monitor, Evaluate and Assess: 

Managing and monitoring service processes to assess and diagnose, etc.

This domain covers the topic of measuring and evaluating IT performance against established standards.

Since DevOps environments are characterized by rapid releases and agility, monitoring should also be performed with short intervals and continuously to evaluate whether the processes are optimized for the DevOps environment created by the business objectives. In this case, it may be more appropriate for enterprises to use automated tools rather than monitoring manually. During this process, you should focus on evaluating the controls around the alerting process and the incident response process. If this is managed by a vendor with SLAs, you should be able to assess how roles are separated in terms of ensuring timeliness and if processes are in place to ensure timeliness.

This may seem like a lot of theoretical stuff for a test like this.

However, if you take what I've described in previous articles and put it into practice, you'll be able to envision things like the following in your head at the planning stage, which I believe are now essential competencies at the delivery level.

Let's say you're performing an IT audit for a company in a DEVOPS environment using the AWS cloud. 

For the first time, you're following the Agile nature of requirements and testing and deployment as a feedback loop, and as part of this process, you can review AWS's CodePipeline and CodeBuild services to ensure that your company's pipeline and test automation processes are leveraging the latest capabilities of AWS.

An experienced In-Charge should also have an understanding of the cloud and be able to review services like AWS Elastic Beanstalk or AWS CloudFormation to envision and interview automated areas of the company's deployment and rollback processes. Identifying these areas as an afterthought can lead to lengthy interviews and a lengthy audit with a complete revision of the initially planned controls, causing fatigue and frustration for both the auditor and the company.

Additionally, DevOps ultimately relies on logging for monitoring, and services like AWS' CloudWatch are well-designed and should be able to provide alarms for monitoring and an assessment of the company's control cycle.

In fact, DevOps has already been adopted by so many companies that it's almost funny to say it's a recent trend. In today's competitive world, it's easy to take it for granted when auditing certain industries. But I think the main purpose of explaining these things is that an IT auditor should be able to think outside the box because the environment can be different from company to company, but I think it's important to be able to audit in compliance with various methodologies and frameworks. It's true that it's important for us to be able to write quickly, write neatly, and of course, we have to perform the audit within a limited time, but at the end of the day, isn't it important to be able to assess the vulnerabilities based on the understanding of the technical parts within the audit period, and to be able to identify the important parts and assess that the IT risk is okay?