The Most Common Blind Spots in DevOps Governance and Compliance

See some of the most common blind spots in DevOps governance and compliance, and learn how to overcome them.
If you work in a highly regulated industry, audits are a fact of life. Yet somehow, even though you know they’re coming, audits never seem to get any easier for your development team. Why is that?
In many organizations, auditing is still an arduous fire drill. If your team isn't sufficiently prepared for an audit, it can be disruptive and invasive for everyone — leading to unplanned work and delayed progress.
So, how can you get ahead of the auditing process to ensure your team is always ready? How can you make DevOps governance and compliance as simple as possible?
It comes down to a shift in mindset. At an organizational level, security and compliance need to assume a higher priority. It’s easy to push back regulatory concerns until the proverbial eleventh hour, but this won’t benefit your team in the long term. In a recent episode of the Software Delivery Leadership Forum (SDLF), industry experts shared a wide range of insights into DevOps governance and compliance, including some of the most common blind spots and how to overcome them. We collected a few highlights of the discussion below.

Blind Spot #1: Neglecting the Importance of Auditing
Historically, organizations have often neglected to audit — until an audit happens and they have to deal with it. But now, auditors are starting to have an opportunity to get involved in the software development process in a much more intentional way. 
Auditors see that opportunity to not just participate and be on a cross-functional team, but be part of that architected solution. Auditors who are excited to leap over barriers and break out of silos of the past and help innovate. 
Rethinking auditing to fully integrate it into the software development process from the beginning will help. Organizations also need to elevate compliance to the level of importance it deserves.
For example, software delivery, as well as security and compliance, are considered equal partners. Each is a first-class pillar to all we’re doing. They're very important and critical to the success of the platform. Risk and Audit teams are key business partners and an extension of the team, participating in requirements gathering, demonstrations, and architectural designs. We should have security personnel embedded in development teams.

Blind Spot #2: The Idea That “What Worked Yesterday Will Work Tomorrow”
Many organizations operate under the assumption that regulatory concerns are static, but in the new world of containers and the cloud, what is? Audit and compliance processes will need to adapt soon.
The cloud and container technology is a true paradigm shift, in that you have to think very differently to get the benefits of that environment. So, the audit and compliance processes that existed yesterday probably won't work for the new world that’s coming. The requirements from the regulators are not as fluid as technology has been over the same time period. Most organizations forget that and try to adapt existing processes to better workflows when actually, we need to totally rethink compliance for this new world.

Blind Spot #3: Negative Thinking Around Compliance
Development teams often approach audits with dread. Across development teams, there’s typically a lot of trust, but from an audit perspective, very little verification. And so, when it’s time to audit, it’s an invasive and time-consuming process to go through every component of every team and every application and track down the necessary data. It’s also time spent away from business value-generating projects, which is a step in the wrong direction.
Teams need to be able to capture data for audits in an automated way. The DevOps approach, where teams shift left and automate as much as possible, has paved the way for better documentation, testing, and compliance throughout the software delivery lifecycle, not just at the very end. It helps to be able to capture information in a way that’s meaningful for reporting for compliance and regulatory requirements.
At an organizational level, there should also be more education around compliance — after all, it’s critical for ensuring the safety of the organization and its employees and customers. We need to make sure that compliance is not seen as a negative thing, and it’s not seen as a hindrance or a deterrent to going fast. It just needs to be much more contextual, and it needs to be in the process rather than something that happens at the end

It’s easy to say and tougher to do in an organization, but developers and compliance can collaborate better if they understand the other team’s challenges and successes. Better empathy and understanding on both sides will go a long way.

We Provide consulting, implementation, and management services on DevOps, DevSecOps, Cloud, Automated Ops, Microservices, Infrastructure, and Security
Services offered by us:
Our Products:
Our Solutions:
For Demo, videos check out YouTube Playlist:
If this seems interesting, please email us at [email protected] for a call.

Relevant Blogs:

Recent Comments

No comments

Leave a Comment