At some point during any maturing security model you'll want to consider the drivers for the controls being implemented. Chances are that the drivers will be a set of corporate policies that cover the use of your technology and the corresponding data real estate. In turn, those policies could well be derrived from a process driven by your organisations' compliance, governance and risk controls process. Then, depending on your industry, you could also expect some regulators will also want to 'have an input'.

In terms of workflows, this process could look simlar to the below ...

I will borrow the 'shift left' paradigm often talked about in the context of the development lifecycle and apply it to this topic. If we were to adopt a shift left mindset, we could try to automate as much as possible around the policy creation and implementation process.

A shift left approach in policy definition means, literally speaking, trying to define your policies either directly in code (or a DSL) OR at least very close to it. Doing so will make it easier to derive the subsequent security and monitoring controls that follow the policies. When successfully combined with Infrastructure-as-Code, the first diagram above could be updated to something like ...

By using policy-as-code and shifting left in this process chain, dependencies on human input can be reduced at one of critical points in the chain. This results in not only freeing up resources to focus on other tasks but also reduces the human weak link that exists when interpreting a policy document in order to transpose it into a set of controls that need to be applied.

There are already a small but growing number of organisations and solutions working on tools to help with implementing a more policy-as-code approach to defining the link between policies and the resulting controls. Hashicorp is one with their Sentinel offering and others are also emerging.

This is a topic that I'm following closely whilst I develop some ideas in this space.