TL;DR

Start writing down why decisions are made. Future you may thank you. Future other person who’s wondering what you were thinking may also thank you.

Then keep a dependency graph of the things impacted by the decision. It will help unravel what gets woven around it.

Background

I was at an excellent AFCEA event last night where former GCHQ CTO Gaven Smith CB gave a presentation “There’s nothing artificial about intelligence and security”[1].

Gaven allowed plenty of time for Q&A, and as we got towards the end of that the questions converged on a common challenge:

How do we innovate within the confines of existing governance structures?

This immediately got me thinking about policy debt, something I’ve written about here before, and a common topic for discussion on the Tech Debt Burndown podcast that I do with Nick Selby[2]

What can be done?

My previous post was frankly weak on this question, and I’ve had a few more years to think about it.

What were they thinking?

Sometimes it’s obvious why a piece of policy is there. A law was passed. A regulatory framework came into effect. There’s a good trail of breadcrumbs in the references.

Other times… not so much.

Which is why it’s important to write down why. So when the shifting sands that we built things on have changed we can come back and figure out if the original premise is still valid.

To misquote a common saying about trees:

The best time to start recording decisions was 20 years ago. The second best time is now.

Who did we tell?

Once a policy is in place it starts interacting with compliance obligations. Auditors will check boxes because the policy is there, and there’s evidence from a control framework that it’s being properly enacted.

So if we want to change something we need to figure out the dependency graph of those compliance obligations. Can a revised policy with new controls also satisfy those obligations? Maybe; but we can only reason about those things if the graph is understood. Without it we’re left guessing, or worse sent off on a treasure hunt to figure things out retrospectively. That’s a lot of work, and not much fun, which is an obvious source of inertia.

Have you seen good tools for this?

I encourage the use of decision logs (and particularly architectural decision records [ADRs]) to keep track of the why? But I’ve not seen much in the way of managing the dependency graph.

I think compliance bus (as opposed to compliance projects) approaches that I’ve seen in some banks are helpful. But more so in an assumed accretive environment rather than one where there’s active effort to undo the sins of the past.

Notes

[1] Refreshingly it was a lot less about AI than the present zeitgeist might have implied.
[2] Season 3 is in the can and almost ready to hit the wires. I hope…