I keep hearing from some DevOps leaders that compliance is a pain in the behind and they spend an inordinate amount of time on compliance certifications. Would like to hear more viewpoints.
I wear both a DevSecOps and a System Architect hat at work so take my experience with a grain of salt.<p>I spend maybe half of my time working alongside developers to define security controls that need to be added, verifying they were implemented, and testing production. I do this because I realized when reading <i>The Phoenix Project</i> that the only way for security to be taken seriously by a company, I have to have an integral hand in the SDLC. Ironically enough, by defining the security controls that must be put into scope this early in the process, I also am able to make sure our software maintains compliance. This experience will be very different for a company that has more technical debt then we do, keep in mind.<p>I spend maybe 10% of my time on compliance. However, this is because we've already achieved our benchmarks; I only focus on determining violations, remediation, and making sure the company is ready for the next audit. Like I said, we have little technical debt and I work tirelessly to make sure security controls have been identified before the scrum starts. Back when I was working to get us to this point, I spent perhaps 90% of my time learning about the compliance benchmarks we needed to achieve and when needed to happen for us to get there.
I work with companies < 50 people and do not hear this. Most of them are first looking for stability and velocity, then security.<p>Where I do see compliance come up is from customer demand or niche applications (healthcare). Even so, compliance is more about people and paper than technology, so yeah it takes longer, it's bureaucracy!