I’m going to start today’s email with a bit of a warning. There are no cute and fuzzy bunnies in today’s email. If it’s not a step off into the deep end of the pool, it’s at least enough to help you stand at the edge, look down at the crystal-clear water, notice the movement and reflection of the light patterns racing across the bottom and wonder, “Just how deep can this thing really be?”
If you’re up for something lighter, there’s always the “frog guts” post archived on the blog…
Otherwise, strap on the swim-fins, and here we go…
When we talk about “governance,” as I mentioned before, it implies that there are certain identifiable “things” that we can control, influence or regulate. That’s the definition. And so that implies, in particular and in relation to security – whatever that is – that we can identify a certain set of “things” that are interesting and useful for us to control.
Why would we want to do that?
Well, it’s obviously so we can accomplish that most basic of human desires: to get what we want.
So, the above begs some questions we need to answer…some decisions we need to make:
What do we want?
What are the “things” that are most important for us to control in order to get what we want?
Recently, I was re-reading David Bohm’s Wholeness and the Implicate Order, and I ran across many things that are relevant and useful to the concept of governance—not to mention things that, in some way, inspired my current thinking on governance from as far back as 2005/6. One of the quotes that jumped out to me today was this one:
“To be confused about what is different and what is not, is to be confused about everything.”
If we’re SABSA geeks, we have a handy tool to identify the boundaries between things that are different, and a means to identify the characteristics that define those differences. Now, this isn’t overtly stated in quite this way – or really highlighted – in the core materials, but it’s clearly there—and fully intentional.
A domain boundary gives us the definition of the distinctions we need to understand that might be useful in getting what we want, but when we talk about those divisions, there’s a problem we need to solve:
Which divisions matter most?
Leading directly to the corollary questions:
At what time?
And for what purpose?
And here lies the problem when we’re talking about “security” governance. While there have been a great many descriptive pages written defining what it is, how it works and what an organization needs to have, there are ways to interpret these definitions in ways that are arguably correct…
…and yet miss the mark for effectiveness by a wide country mile.
We can govern our controls. We can assign the roles and responsibly for identifying and codifying the most applicable “best practices” we think are appropriate for our organization, and yet…
…we’ll still probably have a good chance of a Disney+ front-page experience.
Comprehensive, documented governance of the mechanics is still wrong if we’re doing that in a silo, and this silo is arbitrarily defined by broad definitions of what security means.
Over the last couple of months, we’ve talked about ways to look at the organization, how to get into the worlds of our customers as directed by the principles and practices of The Agile Security System™, and we’ve even talked about the different ways to identify and classify risk within the organization so that we can more effectively connect and communicate the value of what we do every day.
The upcoming December issue of the Security Sanity™ print newsletter now builds on all of this to try and figure out how to identify, classify and correlate the various types of decisions our security customers need to make so that we actually have a clue what to do on a day-to-day basis in delivering our mission and purpose of security to enable the organization to do it’s thang as quickly and safely as possible.
And part of that means knowing who cares about what…who has the ownership of which decisions…and how those decisions relate to the decisions we need to make in our world…
…so we can ultimately build a model that helps us understand the scope of what we need to do…answers the question of “what do you mean by security?” and gives us the hooks we ultimately need to communicate the why’s, wherefore’s and WTF’s of what we do back to our customers in intelligent ways…
…so we get what we want…
…and we help them get what they want.
Governance isn’t “a thing”. Governance is *everything*. It’s the glue that holds the whole kit together. It’s what unifies all the fragmented pieces of our organizations into the coherent whole that, hopefully, works together towards a clear mission and purpose to add some kind of value in the world.
If you’d like to take a peek into how you can try and get your hands (and head) around this wily beast, then you’d best make sure you’ve subscribed before the end of the month so you make sure you’ll get your copy.
Here’s the link:
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
