How to get DevOps into compliance, and vice versa

Why communication is a pivotal factor

Good governance in a DevOps setting starts with communication; compliance folks, auditors and the DevOps staff need to be talking to each other. This sentiment applies to questions about how the pipeline works, getting everyone to understand some process, and how the DevOps team obtains permission for a particular approach.

Clearly communicating the nature of -- and the ways to navigate -- existing processes can positively affect software delivery performance, according to the DevOps Research & Assessment (DORA) in their 2019 Accelerate State of DevOps Report. "Survey respondents with a clear change process were 1.8 times more likely to be in elite performers," the authors of the report said. When team members better understand how to get changes approved, such as for assessments of compliance obligations, it smooths the change management process.

The manner in which a DevOps team assesses compliance, called a control activity, determines whether or not it achieves a control objective. Risk and compliance teams should map compliance obligations to control objectives, thus meeting a shared understanding of and adherence to regulations.

Here, communication helps both parties clear up compliance issues. These should be face-to-face discussions, Herbert said. Risk and compliance teams should use terminology that the DevOps team easily understands.

Traditionally, compliance professionals like to tick items off a checklist prior to release, but they should let go of this mentality, Herbert said. It's more efficient and constructive to entrust DevOps teams with compliance responsibilities for their code changes. Risk and compliance teams should provide guidance and intervene when a DevOps team calls upon them. DevOps teams want a boiled-down description of exactly what they can or can't build and deploy. But IT people should feel like they have freedom.

"IT people [say,] 'Just tell me what to do,' and the risk and compliance people are going, 'Well, there's lots of different way you can do it," Herbert said. "The risk and compliance people, often they don't like to come in and say, 'You have to do it this way' -- the auditors absolutely don't. They like to go, 'Tell us how you're doing it, and then we will tell you what's wrong with that.'"

Betz, of Forrester, envisions a future where IT organizations automate any binary yes or no compliance checks. "And then what I think is left for [auditors] to do, it's going to have to be more advisory -- more consultative," he said.

Code ownership and peer reviews

If risk and compliance professionals take an advisory role in DevOps, IT organizations might want to foster code ownership among individual development teams. If a dev team is responsible for a service, team members should review changes to its code, as well as completely manage all related tickets and their descriptions.

In many IT organizations, change advisory boards perform these sorts of code checks -- yet they can actually do more harm than good when it comes to code quality, Herbert said. With change advisory boards in place, developers don't feel ownership of the code, and the board likely won't understand code-level changes as well as the team itself.

"We often drive it down to the individual teams," he said, referring to Atlassian's internal compliance audits. These teams know the code and what the service does, and should use that knowledge for peer reviews. "Consider yourself to be a co-author on the peer review," he advised.

The DORA report supports this idea. It found no evidence to support that formal approval processes lead to higher quality software. Quite the opposite -- it states that the introduction of more approval steps results in slower delivery, less frequent and larger release batches, as well as more risks for production systems.

"We recommend that organizations move away from external change approval because of the negative effects on performance," the State of DevOps Report asserts. "Instead, organizations should 'shift left' to peer review-based approval during the development process." With shift left, developers perform tasks, such as security or QA checks, early in the SDLC, rather than hand off those duties.

Also, governance models that hinge on practices like biweekly reviews and an overabundance of stage gates might be outdated, Betz said. However, he believes change advisory boards can still be useful. They can follow practices such as change credit ratings, which are metrics that capture a team's track record with change requests. A team that sees its changes regularly fail will earn a poor credit rating, Betz said. Conversely, a team earns some autonomy when changes never cause problems.

Each peer review's degree of scrutiny depends on how much risk the IT organization is willing to take with that team's service or app, Herbert said. Some teams want fast approvals, while others rely on deliberate, experienced reviewers. Determine the appropriate peer review scrutiny level on a case-by-case basis, according to the application and its compliance obligations.

Role of an integrated, end-to-end release pipeline

The payoff from a fully integrated, end-to-end release pipeline for governance processes and compliance is information, XebiaLab's Beauregard said. Pipelines collect all kinds of info, from all places in the software delivery process, for use in predictive insights and data analytics.

DevOps teams can codify and design compliance controls right into the pipeline, and automate as many processes as possible. Risk and compliance professionals want to know how code release pipelines work, Herbert said. At the same time, DevOps professionals want to know how compliance can work in one. He tells both sides to talk more.