Compliance as code

Podcast Transcript

Rebecca Parsons:

Hello everybody. Welcome to the Thoughtworks podcast. My name is Rebecca Parsons. I'm the chief technology officer for Thoughtworks and I'm here with Satyam Agarwala and we're going to talk about an extension really of a governance automation. In the past, we've talked about governance automation with respect to architecture and we're going to have a little bit different take on it today. Welcome Satyam. Would you introduce yourself?

Satyam Agarwala:

Thanks, Rebecca. My name's Satyam. I'm a lead consultant with Thoughtworks Australia. I started my journey in Thoughtworks seven years ago as one of the first employees of our Singapore offices and I work with a variety of clients across different domains, mainly focused on financial services over the past seven years.

Rebecca Parsons:

And you tossed out a phrase when we were talking about this earlier, compliance as code.

Satyam Agarwala:

Oh yes.

Rebecca Parsons:

What does that really mean? I mean, everything's as code now. Infrastructure as code, all of this. What does compliance as code mean?

Satyam Agarwala:

Oh yes. Everything as code, is almost become a bit of a fad, but I think compliance as code really is about how we push the boundary on agility. We've seen over the past two decades that we've managed to deploy our code faster, make the ability to deliver value to our customers faster. But we were starting to hit certain boundaries and we see that especially in regulated industries where there are strong compliance requirements, rightfully so on these industries such as financial services. And their ability to deliver value to the customers is inhibited by the GRC processes or governance risk and compliance processes. Within the context of GRC compliance as code really aims to make some of these processes automated, but also not just automated, but more transparent, more deterministic, and also shift left on these processes, so that the cost of change due to any issues found with compliance can be tackled a lot earlier.

Rebecca Parsons:

Okay, so we're extending the scope of influence. We've moved past just the security department and now we're talking to the compliance folks.

Satyam Agarwala:

Absolutely. And I think that's necessary because when you speak about regulated industries, you do have a responsibility to act in the best interests of your customers. That's true about financial services, medical industries and government. Tomorrow, it will be true about self-driving cars when software updates have to be pushed out to them. So you have people's lives, people's money, people's livelihoods. You have the responsibility of safeguarding those. So there is a necessity to make sure you adhere to these processes. Now, with all of the technological advancements we've made over the last two decades, you want these processes to be as automated as the way we do software development today so that we don't slow down the delivery of value to our customers. People expect new features, more value creating features as part of their daily lives. And we don't want to stop on that.

Rebecca Parsons:

But you also don't want it to have glaring compliance issues, which might result in a fine or a breach or something like that.

Satyam Agarwala:

Absolutely. And you don't want to cause harm to your customers because at the end of the day, their success is your success.

Rebecca Parsons:

Yep. Great. So how would you compare this to something like the DevSecOps movement. We actually had a podcast that debated whether or not that term made sense or not, but the concept is still there as we're trying to bring security into the fold. And as mentioned earlier, I do see some parallels there. So how would you relate what we're trying to do here with compliance as code, with some of the objectives of the DevSecOps movement?

Satyam Agarwala:

I think that the idea of compliance as code isn't new, right? So it isn't something that was born in the last 12 months. Definitely not by me. As far as 2014, 2015 there's literature by some of the leaders in the DevOps movement, folks like gene Kim, talking about DevSecOps, but also talking about bringing audit and compliance functions into the fold. Because whenever you ... Even with the DevOps movement, if you brought those principles into the larger regulated spaces, you still have to answer those questions. You still have to deal with GRC functions, whether it was DevOps, whether it was Agile, whether it was Lean now cloud-native, right? So you have to deal with that regardless.

Satyam Agarwala:

There has been thought leadership around how you bring these functions into the fold. Where we are, today's different to where we were five years ago, is that the technology landscape has moved significantly. We've entered this hyper automation cycle with the public cloud and, really, our ideal processes changing over to Terraform and being able to manage infrastructure and networks and firewalls all as code. That's really changed the nature of the game.

Satyam Agarwala:

Our ability to deploy has become order of magnitudes faster now than it was five ago and that's actually exposed the bottleneck that is the GRC functions, within larger regulated industries. And this is most evident in the financial industries and there's another reason for that as well because the incumbents are being challenged. Open banking or the opening up of the ... The advent of new banks whether it's Monzo bank in the UK, the N26 in Germany. All of these new banks that are really challenging the age-old banking model. So the incumbents who are bogged down by heavy processes have to, not only respond to competitors, not only have to deliver value to their customers faster, but they also have to protect themselves from their competition being eaten by these fintechs and ... Neobanks were obviously a lot more nimble than they are.

Rebecca Parsons:

And do you think the existence of these new challenges within financial services, do you think that has also provided something of a counter to the "Well this is the way we've always done it and you have to do compliance and risk this way because that's the way it's always been done." I mean, clearly these other banks have to have some level of compliance. They have to comply with the law.

Satyam Agarwala:

Absolutely.

Rebecca Parsons:

They come manage their risk and to so do you think that, that provided that impetus that said, "Well actually it is possible to do it a different way because these guys are doing it"?

Satyam Agarwala:

Exactly. I think that the incumbents have had to look at the entire software supply chain and figure out where they're going to have to optimize. Right? Because as you say, the challenger banks are doing it. They are building from ground up. They don't have the 180-year legacy that some of these organizations have, a hundred-year legacy that these organizations have. So their processes have matured over decades, the incumbents and they're comfortable. Change is hard.

Satyam Agarwala:

Inertia. We are all resistant to change, right? But these challenger banks, they've come into a ecosystem where the public cloud is a reality. When the larger banks started operations, you has to run your own data center. Right? So you didn't have some of the technological advancements that the new banks have. Monza bank, for example, has publicly spoken about how they've built the entire banking infrastructure on Kubernetes. That's not an opportunity that the larger banks had.

Satyam Agarwala:

So, there's obviously been an impact [inaudible 00:08:38] that if these banks are able to do it, we should be able to do it as well. So it's shown that there are those who are motivated enough to do it, but on the other hand there's also that financial regulators have opened up the doors doing this. And the open banking movement is the most direct evidence of this where they've ... The idea that data needs to be democratized and therefore once you lose a stranglehold on your customer's data and the customer will go wherever they have the best experience, right? Because they are now in control of their own data. That has not landed yet in Australia but it will very soon and we're already seeing effects of that in other markets.

Rebecca Parsons:

So we have a change in the regulatory landscape, we have a change in the competitive landscape. You've talked about some of the motivators or the impetus for change with things like Kubernetes with public cloud. What are some other technology changes that are supporting this notion that even in a traditional bank we can do something like compliance as code?

Satyam Agarwala:

We've had a few advancements such as infrastructure as code or defining our application configuration as code. What that's enabled us to do, is because everything has defined as configuration, technologies like Open Policy Agent, which allow you to define policies and test your configuration before deployment have really taken off. Even in the Kubernetes landscape, enforcing those policies in the form of admission controllers has allowed us the ability to show that these controls are enforced.

Satyam Agarwala:

There are other technologies such as Binary Authorization from Google, which essentially produces cryptographically signed ... Using public key cryptography produce signed attestations, which reflect that a certain process that you expect to have taken place has taken place. So the assurance that a certain process has taken place, for example, could be a unit test, could be a design review. So processes that you expect from machine actors or human actors have actually taken place before code is applied.

Satyam Agarwala:

And that essentially is our change management process, right? Which contributes to governance when it comes to IT change, change management within software. So a few of these technologies have really come together to provide the Lego blocks or the building blocks for governance code. On the challenging side, these are just tools. You have to bring your organizational context to the party to actually make this a reality. And that's where challenge is, because every organization is different.

Satyam Agarwala:

Yes, there are patterns across the same industry, but every organization treats governance and risk and compliance or the interpretation of regulations differently. So your organizational context last ... All of these advancements have to come together to make compliance as code quarter reality.

Rebecca Parsons:

Well and it seems to me too that it requires a particular kind of chief compliance officer or chief risk manager to actually conceive that something like an automated process can work in this context. Because you know, ultimately the chief compliance officer is responsible for certifying to the organization. Yes, we're compliant. So to me that looks like it's a big social change as well. And it's, as you say, organizational context really matters there.

Satyam Agarwala:

I think control owners within the organization have to come to the party, right? For example, if you take security, your chief security officer has the control and the accountability of maintaining that control within the organization. So if you look at governance process for change management, it can essentially be modeled as a series of control points. For each of them, you have to provide some evidence showing how you've met that control point before the change that you want to deploy into production to create value for your customer is sanctioned. We have to take that process and if you want to automate it, then all of the control owners, who are measured on those control points and maintaining those control points have to be empowered to help make this change. The easiest way to not have outages in production is to not deploy anything. Right? That's the safest deployment.

Satyam Agarwala:

So, that same applies here. Why would they change a decade's old process, which works. It's might be inefficient, but it works. So really that organizational leadership and the leadership within the organization has to create the environment of a culture where the necessity to be more agile because of the competitor landscape or what your customers expect has to be ingrained not only in engineering department, but also in the GRC function. So, things like procurement have to become faster. Things like governance and deployment has to become faster and they have to come to the party.

Rebecca Parsons:

So where is this approach in terms of maturity? Are we done yet?

Satyam Agarwala:

No, I think we're fairly early in the hype cycle. These tools that are maturing within the landscape, they're still tools, right? As we touched upon earlier. Patterns will start to emerge, especially when the rubber hits the road and we have to start taking out the manual processes and replacing them with these automated process and you have to bring the subject matters experts whose day job and job performance relies on providing that organizational assurance, we will discover gaps.

Satyam Agarwala:

We will discover that there are certain things that can't be done, but the idea is not to get them 100% even if you can get to 80%, right? Then you create ... It's the same with unit testing, right? Or automated testing. You don't want to get to a hundred percent, no human involvement in the software development life cycle. Your QAs can add value in terms of testing where automated testing might not. But the idea is to provide them the time to be able to do that. Right?

Satyam Agarwala:

You want human beings to create values where they are good at, where machines might not be able to help. But machines are able to help cover 80% of that. So when we start actually replacing the manual processes with these automated process, we will find that there are gaps and there will be a point where we will lose hope in this technology, potentially. The same way we lost hope in the [inaudible 00:16:27] during the orchestration was between Kubernetes and all of the other container orchestrators. Then patterns will emerge. Organizations will come to the forefront with how they've managed to utilize this to improve their operations. And then we can start getting into a rhythm where this actually becomes as ... We start taking this for as granted as we take unit testing today.

Satyam Agarwala:

No one would argue that unit testing is a waste of time and that's required a fair few years to become ingrained as part of our culture in software development. The same is going to take time possibly longer because it involves a much ... It has a much broader scope and a much broader impact as well.

Rebecca Parsons:

Well, and it could be seen as an existential threat to the organization if it goes wrong.

Satyam Agarwala:

Absolutely. Organizations have gone bankrupt because of changes, because of missteps in their compliance or risk processes and organizations, especially large organizations which serve millions of customers will need the assurance that this is a foolproof method.

Rebecca Parsons:

So are there specific skills that you as somebody on the delivery side of this trying to work with risk and compliance? Is this just like any other feature development or do you have to bring particular skills to this development? Because you still have to write this compliance as code. There's the analysis process of how do we take this particular compliance process and and automate it? Is this just another kind of software development or do you think there are more specialized skills that you need to bring to this? Or is it too early to know?

Satyam Agarwala:

A bit of both. More than skills, you need to bring empathy to the process with those functions, right? So, the same way with infrastructure as code, you have to bring empathy to the process of what are the ops functions do and how can we make that better? But what can we learn from that process as well? So I think the same will apply with trying to automate the GRC functions.

Satyam Agarwala:

We need to understand why those functions exist, what value they bring, and also be able to speak some of that language. So be able to speak the language of the balance of risk and value creation. We need to understand some of that and able to help our colleagues in [inaudible 00:19:13] who perform these functions to make their lives easier. Because at the end of the day, that's what this is about.

Satyam Agarwala:

It's about making someone else's life easier, whether they are part of your organization or your customers. So I think that empathy we, as software developers, have to learn that empathy. But I think it's about good software engineering practices, right? This is not a completely new field. We are bringing what we've learned over the decades, the movements that we've pioneered, like DevOps or Agile, bringing all of that thinking to the next level, to functions which have historically been outside the tent when it came to those movements. So that's what I think will be most important coming over the next few years as this discipline matures more.

Rebecca Parsons:

So we're continuing to expand the role of automation in actually bringing real systems, solving real problems, even due to life altering problems for people, architectural governance, security, governance, and now GRC automation. That's fantastic.

Satyam Agarwala:

That's the future.

Rebecca Parsons:

Well, thank you very much for joining us.

Rebecca Parsons:

Any advice for people who perhaps want to get involved in this other than care about compliance and and have a little empathy for someone whose job is on the line if you get things wrong.

Satyam Agarwala:

I think, like I mentioned earlier, we have to start small, and this can start ground up. You don't need a top down cultural change to actually affect this. All of the technologies we spoke about earlier are open source and you can give them a try, like Open Policy Agent and they can provide real value to you just within a small team.

Satyam Agarwala:

The other aspect is this is not just a large organization problem. Even if you're a startup and you want to have some governance when you deploy code to production because you carry a reputational risk if few things go wrong. You can now also get immense value out of it. So all engineers, I would say that we need to put our risk hats on and see whether we can improve the processes that we go through.

Rebecca Parsons:

That's fantastic. Thank you so much, Satyam for joining us and we have a new S code to add to that vocabulary. [crosstalk 00:21:53]

Satyam Agarwala:

Thank you so much Rebecca.

Neal Ford:

And on the next episode, we're going to talk to Gregorio Melo about his new book on functional programming with Closure. Stay tuned.