Now, at the legislative and regulative layer, you can save a lot of effort over time by designing the “structure” of the specification to be modular and reusable

That works in enterprises as well!

Well, all the way up to “implementation.” For implementation… it depends

Manually implementing a regulatory obligation is actually quite nice, all things considered: you write a few documents, train people to follow the process, and create a paper trail that’s audited

If the regulation changes or evolves, the documents get updated in a clean manner and all is well
Automatically implementing a regulatory obligation, on the other hand, is utter hell. Automation in general is hell.

If it’s automated, you have to make an automated paper trail, automated measuring system, automated process, and so on. Both for the process *and* for showing that it wasn’t bypassed

That “showing it wasn’t bypassed” is particularly important. It means you need to understand the entire state space of what’s possible in the whole automation, and you need to exhaustively demonstrate fulfilment of the obligations (“within reason”)

In other words, anything dynamic is a fools dream

Imagine trying to take a Kubernetes operator and show that no matter what happens in the cluster, certain things cannot occur

Luckily, regulation isn’t quite at the level of “formally verifying arbitrary properties of complex systems” … but for automation it can get uncomfortably close

It gets even worse: That is *per* obligation

If you want to fulfil two obligations, the manual method scales extremely well. Most of the documentation structure carries over, and all of the training process, audit trail, etc, is typically reusable

If it’s automated, almost none of that is reusable