Bill Bensing

Awesome. Thank you all very much.

I am going to have a warning, I guess. I guess the new kids call it a trigger warning these days. I am going to rip apart policy as code today. So for anybody who's hardcore believing in this, hold your applause.

But before I start, I do the Gene ask. I need your help. I want to research how you do policy, so shoulder-surf, that kind of stuff. But also, because I need your help, I'm also willing to help. So for today, the companies that are here now, it's not per person, but it's per company, I'm willing to offer four hours of my time to work with you and your teams on the content that I show today, if you believe it's valuable.

With that being said, I do have one rule of my presentations. I call it my Beyoncé rule, right? My little "if you like it, then you should tweet on it." Or if you're on LinkedIn, go ahead and LinkedIn it, right? So have at those already.

With that being said, bottom line up front. I want to get straight to it. I'm going to tell you what I'm going to tell you.

Policy as code is an unfortunate and misleading colloquialism. And I can't quite pronounce that, but why I use that word is because a colloquialism is a word that describes something that's familiar and informal. And I did a little research on policy as code because my question was, where did this come from?

Using Google Search and the Wayback Machine, somewhere around 2014, 2016-ish, AWS and a bunch of cloud vendors started using the term policy as code to sell more infrastructure services for PCI and HIPAA compliance, is what I could get to. So when I ask things like, where did this come from, is there a fundamental thing it came from? It came from a piece of marketecture. So I thought that was interesting. Now, I'm willing to be wrong on that one. If you find something different, let me know.

Question to you all: what do all of these words have in common?

Thinking about it, they all mean something different today than they did 20 years ago. For example, text. Twenty years ago, that meant a book. Now it's on the phone.

Let's talk about stream. A stream used to be this beautiful-looking thing. Now it's this other thing.

The word policy is another one. Policy used to be these big nouns. Some people have policies. But for us in the room, a lot of us in the geekdom, policy is what looks like on the right-hand side.

So I have a mission and a big idea: can we actually make policy mean something again, or make it start to mean something at our level?

Bad policy. When I say bad policy, I'm not talking about no policy. I'm talking about no clear and direct link between your high-level intentions and your low, low, low-level activities.

And when I talk about a good policy, there's an irrefutably clear and direct link between the high-level intentions of your company and your low-level activities.

So to sum the bottom line up front, policy as code is misleading. I'll say there's no such thing as policy as code, because you cannot codify policy. A good policy is connecting high-level to low-level activities, irrefutably.

And there's no intro slide, but as everybody can see on anything, I'm Bill Bensing, one of the co-authors of Investments Unlimited. One thing that we talked about, but we never got to in the book with a lot of this, was what is policy as code? So look at this as a little bit of an extension there.

A bit of the agenda today: I'm going to give you a policy as code 2.0 strategy. I can't think of another word besides policy as code. It's such a great piece of marketecture. When I do, I'll let you know. But a good strategy has a clear diagnosis, some guiding principles, and coherent actions you can take.

So let's get started about what is policy. Question to you guys: is this a policy?

No.

All right. How about this? Is this a policy?

Let me see. Raise hands for A. Some hands. Raise hands for B.

And it's not a trick question. Only one of these is true.

Well, let's ask first what a policy is. We haven't clearly defined a policy, which is the first problem, I believe, in most organizations: we use this word without defining it.

I'm going to steal a definition from the Secure Controls Framework. I love the Secure Controls Framework. When I look at this, we'll talk more about it today. This gives a clear description of expectations for how you can look at designing governance in your organizations.

So why SCF? I just told you that, jumped ahead. But domain-driven design. If I'm going to design a governance system and I'm going to build according to domain-driven design principles, I'm going to design to the Secure Controls Framework.

So what do they consider a policy? To them, a policy is established by organizational leadership, and it's the management intent for things like cybersecurity and data protection, their requirements, to support the overall strategy.

So let me ask you one more time. Was it A or was it B? One big A? There we go. Irrefutably A. This is management's intent. And I have to thank ChatGPT because they built that for me.

But let's talk about what's wrong with B. B itself is really just a control test script. So what we call policy as code, because I'm at fault for this one too, is really just a control test script. This is low-level. This is low-level activities that we're saying, did these things happen? Did it or did it not happen?

And that's all this is. And that's why I will argue that what we like to refer to as policy as code, that helps sell billions of dollars of software, is not policy as code. What it is by definition, though, is a procedure. And that procedure establishes these defined practices or the steps that are performed to meet some standard or to satisfy controls. We got a couple new words in there: controls and standards.

But what I'm going to implore everybody to do is to go back, and when somebody says policy as code, be like, "No, stop right there. It's a procedure."

This right here is what I call the layer cake. And actually, once you read the Scaling Automated Governance paper, you'll see a bit of this in some of the fourth round policy as code. I love this because this gives us clear definitions, from policy, which you see at the bottom that's supporting everything, to the high-level top of procedures. We'll cover control objectives, standards, and a bit of guidelines today.

But when I talk about creating an irrefutable link, when I look at this, this right here is an irrefutable link to me. It shows me how they stack, how they relate, and how they're defined.

So a bit of our diagnosis: ties between high- and low-level policy are issues. Policy is high-level. Policy as code, the procedure, is low-level. You cannot codify policy. It seems like I have a misprint here, as policy as code is low-level, and I'm saying you can't codify it.

You can codify procedures, and policy as code is simply just a nice way to put lipstick on the word procedures. And policy as code fails, in its existing implementation, to connect high-level to low-level.

Did that confuse you all yet? There we go. Got some confusion here. Great. That means you're paying attention.

So let's talk about how do we cure this one. I have three guiding principles here: governance domain-driven design, a control-centric view, and the irrefutable link between high and low level.

What I mean by domain-driven design, I know a lot of people already know this, but for the folks that don't, give me four slides to explain it. It's a software design approach that focuses on modeling software through how the domain experts, the governance folks, the auditors, define what they do, not how the software person thinks about it. And it's designed around how you think, talk, and act.

In there, there's this concept of ubiquitous language, which are the terms and concepts that are used at the business domain, and there should be no ambiguity about them.

So when I talk about this, the ubiquitous language is not what developers make up or the general colloquialisms they use, like policy as code. So if you're using policy and defining a governance piece of software, it better mean the high-level intent of the organization, not what it means today.

So what's this domain? The domain is integrated controls management. This is part of the Secure Controls Framework. But to dig deeper into this, what is this? I highlighted a couple key points because that's a lot to read, but controls are central to the overall rhythm of the business, and they help define a holistic and important technology-agnostic approach to things such as the people, processes, and your data as stored and transmitted.

So if we talk about defining a governance system in the domain, integrated controls management is our domain. And what's unique is it's different than things like GRC or integrated risk management. Why? Because it's control-centric. It's a nexus around cybersecurity and privacy operations.

So GRC, the governance aspect is central to GRC. In integrated risk management, risks are central. And so this is a difference of perspective there.

Our ubiquitous language, it's back to this. When we talk about policy, control objectives, this is what we all mean here. I will point out there is some work to be done, because if you read integrated controls management, they talk about the stack, but then you'll see these words: control activities, controls, and control objectives. So this is me mapping them on there. They didn't do this, but this is how I look at it.

You look at controls and sort of standards and guidelines, your control activities and procedures, the things you do. Your objectives are what you're trying to achieve.

One thing to note is there may be companies out there that have policies but don't have control objectives, such as NIST 800-53, SOC, ISO, those types of things.

Well, that was a copy of a slide that shouldn't have been in there. A quick observation made: you may not have control objectives. You may have policies.

So as you go through this, let's talk about what a control-centric viewpoint is. Has anybody seen integrated controls management before? Is this new to anybody? Lots of hands. Who's new to ICM? Okay, cool. It's new stuff.

Is anybody using the Secure Controls Framework in what they're doing? I don't see any hands there. I see one hand.

The control-centric viewpoint sort of looks like this: policy, standards, but controls are at the middle. I'm going to talk through what this means a little bit deeper, but the idea is you're focusing on, as an organization, negotiating and agreeing to what the controls are. And we'll talk through some of the responsibilities here in a second.

But I want to show an example of how you put this together. Some people are like, okay, what does it look like to connect all this stuff?

Here's that boring policy, right? I want to ensure all changes in production services, communications that are facing our customer, are reviewed by at least two people. This is high-level. It's very nonspecific. It's intent.

Here's my standard: for all production deployments, the following must happen. An engineering tester must sign off that the current testing sufficiently covers the feature and functionality. And the product owner with P&L responsibility must sign off on the change.

Now what I'm doing is I've started to get more specific.

Here's my control: the deployment server must allow or prevent change from going to production if the constraints of the standard are not met by the defined procedures.

So you see what I'm doing here? I'm taking it from high level to low level. I'm going from why to what we're doing.

Now let's get into the procedures themselves. This is what you can codify. I have two procedures here. One: my engineering test, something. Look at the reviewers on the pull request. At least one must be categorized as engineering test in HR, and then make sure they approved.

Same thing for the second one, a P&L owner. I'm talking about a different system. There's a product management system here. Are they defined in there?

And so if you start going through this, this is how you codify and how you start to build those links.

Is anybody's mind blown?

Now, here would be the gut punch. Is anybody like, "Yeah, I already know this stuff and it's okay, Bill"? And we got a couple hands going on.

So doing that helps to create the irrefutable link. Now I want to introduce something I call the governance graph. We're going to walk through it here.

Remember this control-centric viewpoint. This right here is how we create this irrefutable link between procedures, controls, and up policies. This is management's responsibility here: policies, high-level management intent. Let's establish what the policies are.

Standards is something risk or compliance will help to put together. This is their domain, and they understand how to look holistically and say, what are the things we need to do?

But this right here is the great collaboration: metrics, threats, risks, and controls. This is where, whether it's risk, compliance, the engineering team gets together and they work on what this looks like.

And when we talk about a control-centric viewpoint, that's what this is.

And this is what I call governance engineering: this empirical, observational approach to creating efficiency and efficacy. I'd also like to talk about this as an alpha engineering approach to solving your governance.

And then I have the little teddy bear up there. This is the first time you guys have seen the teddy bear. I was on a podcast recently and talked about good governance is like a teddy bear to your executives. It makes them feel comfortable, right? It smells good.

If you think about it, some people are like, how would you define it? It's a teddy bear. Geez.

This is where we live. This is what we do and what we're responsible for. But what you see here is, if you look at each of these orange, and I'll go back a couple as well, what we're responsible for is defining the procedures, but we also define what controls and we tell how we implement these controls as you start looking through it. So those are the responsibilities that we have.

And now I'm going to tell you that this is good bureaucracy, and bureaucracy is good.

So who's read The Delicate Art of Bureaucracy? Yes. Seen a couple people in here. I love the book. Mark is here today. He argues that when you think about what bureaucracy is, good DevOps, good bureaucracy, it's segmentation of information and flow to create an effective outcome. And so I'd argue if you do this well, it's going to represent a good bureaucracy.

So this is what you can talk about and be like, yeah, bureaucracy is good. Also, what this does, and Beyond Agile Auditing is an example of other good bureaucracy, because what Clarissa talked about in here is doing this facilitates a stronger collective knowledge and clearly aligns the auditors to the clients for a collective goal.

So as I start looking through this and whatnot, it's like you can't get away from the concept of bureaucracy, because bureaucracy, as it's defined, is segmentation of information and flow of knowledge to achieve an outcome. And as you scale, you have to have bureaucracy happen. And what Mark talks about in the book is that good bureaucracies create feedback loops while maintaining that segmentation.

I thought it was funny. I'm going to put it in there. Maybe some other people here are planning, like, okay, I've been bureaucracy-bashing. Now I got to go back to work and be like, "Yeah, bureaucracies are good." Like, it's something.

So if you start to roll this out in complexity, what you're going to start to see here is composition of controls. You start to see basically just your inputs, outputs. You can have complete sets there: controls, metrics, procedures, at your hardware, cellular, application.

This is now what you would start looking at. Let's broaden this out, right? This is where we grow in complexion, because this is our lives. And this is what gets down to the governance graph.

As we do this, we want to create these bidirectional relationships. It's a knowledge map at the end of the day. I think we all use knowledge maps when we're learning. All this is another knowledge map. And connecting this all together, this is how we create these irrefutable links.

A couple constraints here: policies can have more than one standard, standards can have more than one control, and controls can be validated by more than one procedure. Very simple at the end of the day.

But what I love about graphs, and if anybody here is in graph math, you have two questions you can ask: depth- and breadth-based questions.

Here's an example. A depth-based question is something you might seek to understand, the relationship to details through multiple levels of structures. So what if somebody wants to ask, how does procedure A, like an auditor clearly could be there, "Okay, show me procedure A. How does this evaluate the effectiveness of the controls and the overseeing policy and everything?" So that's one question you can ask.

We also get to breadth-based questions, things you want to seek across them. One could be, how do different standards under a single policy ensure you're in compliance?

Let me ask you right now, these two questions: if you were to go back to your organization, could you answer these within 60 seconds? Who says yes? Who says no?

Ah, there we go. That's sort of my litmus mark. If you can answer that complex question across your different versions of your operating systems, your different clouds, all the exponential complexity, you're good. And that's where you want to get to, right? That takes a long time to get there, but that's the goal.

So the governance graph itself is to tie the high versus low. That policy on the left to the procedure on the right is what you want to do. And that's your goal: provide that middle context.

So let's talk about codifying procedures. What do we mean when we talk about codifying procedures?

Something I've been working on recently, it's called NAPE. NAPE stands for Not Another Policy Engine. We don't need another policy engine. John Willis actually, we were at DSA this year, he talked a bit about it in terms of Secure Controls Framework as code, I believe was the term that John was using.

But the idea here, as you look at it, and I want to compare a bit of this to where if you know OPA, if you're looking at Terraform or some of the stuff that's going on there, the idea around this is to explain the how in a very singular way.

Let me go back one. If you look at something like this, the evaluation part, it is single responsibility in one file. You cover how you're doing it and what it's for. The idea is to help to establish this sort of bidirectional knowledge of context of what's happening.

So when you look at this part, what's very important about this, and I'm looking through trying to figure out why do our existing policy engines fail? Well, they fail because they do good geek things for us, but they fail to create and connect in between.

When you look at this right here, this is key. Right now, a lot of people will look at that code and be like, "Oh my God, I could do that in two lines of Rego." Of course. But what you miss in two lines of Rego is if it fails or passes, you miss the direct context.

This right here allows an independent third party that has little to no technical knowledge to understand what happened. And when they can't do that, that's when they come sit on your desk and ask for evidence, and you can't deliver your stuff, and you don't get your bonuses, and all that kind of bad stuff happens, right?

The what at the bottom here, what you're going to see, this is a standard. And what is this doing? It validates that the PR requester is not a PR reviewer.

Now, the idea behind a lot of this stuff is you're going to have hundreds, if not thousands, of these. And with that governance graph and these at the bottom, you work as a governance engineering team to now create this irrefutable link between these low things that I'm doing, these geek activities. So I'll call it the board-level activities, right? You got the board geeks and the tech geeks at the end of the day.

One last aspect of this: explainability is first class. If you look at this, this is an outcome created in the open source. It goes through. It tells you exactly your standards, what passed and what fails. It tells you why it passed and why it didn't fail, and what it was doing.

So let me ask this. I don't believe I'm probably recreating this, but is anybody doing this right now with your existing policy as code approach? I see no hands. We got one-ish hands.

Let me ask this: do you think adopting something like this would help clear the burden of compliance and audits from what you're doing? Yes, I see some heads. You can say no. Thumbs down, thumbs up. It's sort of like a Sparta thing, right? I see thumbs up right here.

So explainability is first class, and I think this is key when we talk about codifying procedures. And this is one thing I want to hammer home. It's not just saying, look at this value in this file, do this, do that. It's explaining why to the independent, nontechnical third party what you're doing.

So at least if they have a conversation, it's deeper than, what was the activity you did? There may be deeper questions into understanding this act. And the beautiful thing behind this is what it does is it frees up our risk and compliance people to do what they do on a daily basis, which is try to understand what better controls and what are the other risks our businesses are facing.

So with that being said, I'm going to draw a little conclusion here.

Policy as code, again, it's an unfortunate and misleading colloquialism. So I would implore people to stop using it. I know overnight it's not going to happen. If I'm successful, it will happen, but we'll see, right? Every DOES from now on, we'll come back and see how successful this is.

Code procedures, not policy. You want code written for the proper domain. You want to centralize in controls. You want to ask yourself, what procedures do we need to create to test the controls? Because what are the procedures? They're just a control test at the end of the day, and that's it. They're not policy as code. They're control.

And the governance graph, as you are doing this, the goal is to create the irrefutable and clear link between the high-level and low-level activities. And if you've done this, you succeeded.

And if you want to do this, you do it with the governance engineering team. The idea behind this, and we started talking about this a bit last year and see a couple people talk about it in the industry, is how do we, and I think about SRE. And SRE really inspired me when I talked about this last year, because it was the idea of having software engineers solve a governance problem. It had been trying to solve this as an infrastructure problem.

But the idea also comes down to the associated sociotechnical agreements. You think about what SRE does. It allows the product teams to focus on product, and SRE can help scale. But what does governance engineering do? It allows the product teams to focus on product, so then the governance engineering team can help scale the risk management and controls management.

So if you look at that type of sociotechnical outcome, as we saw earlier with the dev experience and dev platforms, the best way to introduce this is as part of a platform: adopt my golden path. If you take my golden path, you have all of our compliance and whatnot built into it. Therefore, you don't have to worry about the burden.

Again, hold me to my four-hour promise if that will help you. eTestify is a new open source I've been working on. You'll see some of this up there. I'm working on better documentation, but you can go play with this right now and join the governance engineering movement at governance.io.