MMS • RSS
Article originally posted on InfoQ. Visit InfoQ
Compliance is about making sure that you are doing the right thing and being able to prove it. With agile and frequent deliveries you need to build compliance into the process of delivery. Making compliance obligation part of the thing that DevOps teams own increases the likelihood of success.
Guy Herbert, risk futurist at Atlassian, explored how you can be compliant in an agile world at the Atlassian Summit Europe 2018. InfoQ is covering this event with Q&As, summaries, and articles.
Every organisation is subject to some form of regulatory obligation, said Herbert. They sell a product and there are rules around that. They hold customers’ information and might be listed on an exchange; there are rules around that. Herbert stated that compliance is about making sure that you are doing the right thing, knowing that you are doing the right thing and being able to prove it when people ask.
You have to build compliance into the process of delivery, argued Herbert. In the past you could try to “bolt it on” just before delivery because change was delivered every 6 months. But now we are trying to deliver multiple times a day – there is no way that you can add it on at the end.
InfoQ spoke with Herbert about ensuring compliance when you want to deliver frequent and fast, how Devops can help to solve compliance demands, and making existing compliance systems more agile.
InfoQ: How do you ensure compliance when you want to be able to deliver frequent and fast?
Guy Herbert: At Atlassian we get the teams to understand that risk and compliance are part of the delivery, we give them the context of what we are trying to do and they own the risk and compliance aspects of their work. We use peer review as a key change control and we make sure that the work passes testing before it goes to build.
Most agile development teams use peer review and testing – it is a great way to get quality into the code – but what makes us different is that we use Bitbucket to system enforce that peer review and green build.
We give the teams the ability to make change – but we also tell them that there are things that they have to do – if they want to change the minimum requirements, they need to talk to us – if they are meeting the minimum then there may be no need to involve us. We then ask them to confirm every 6 months that they are doing the controls that we have discussed with them (for example the processes around user management or change control). And we also come and check to make sure that they are. For the controls that we can automate (like automated user provisioning and removal) we don’t need to come and check as often – we just confirm that they are configured the right way.
InfoQ: How can DevOps help us to solve compliance demands?
Herbert: For DevOps teams there are often lots of compliance obligations – what the risk and compliance teams need to do is break them down so that the people doing the development and operations work can do their work and also deliver the obligations at the same time. An example is change management – almost all of the compliance obligations rely on a controlled change management environment. If you implement that once then it can be used for every obligation – that means that you don’t have to implement a different change management control for every obligation. This is a simple example – there are lots more, and the risk and compliance people can either make this really easy or really hard depending on how they set these up for the teams.
We also see that DevOps teams have a higher level of engagement and ownership – making the compliance obligation part of the thing that they own increases the likelihood of compliance being successfully delivered.
InfoQ: What can be done to make existing compliance systems more agile?
Herbert: Getting a better understanding of what compliance obligations each team is supporting so that they are not focused on the obligation but on the control activity that supports that obligation will enable the teams to change when they need to. The team then knows the control activity that needs to happen – and so as they change they can move that to a new team or talk to the risk and compliance team about potential changes to the control activity.
At Atlassian we talk about our control objectives forming an abstraction layer between the control activity that the team performs and the compliance obligation that the organisation must meet. This allows the delivery teams to focus on their work instead of each compliance obligation.
I believe that the risk and compliance teams should be looking for ways to help the teams meet their compliance obligations in a better way. Is there something that the team already does that you can use for compliance instead of implementing something on top of what they already do? Peer Review and Green Build is a great example of this.