It’s 2nd time in last 24 hours that the subject of “Reporting lines”, also prompted by this article (https://humanisticsystems.com/2019/07/04/the-organisational-homelessness-of-human-factors/) relating to Human Factors, but I think to an extent it affects #Infosec as well, has come up so thought I’d put some quick thoughts down on the subject.

Where should #Infosec report ? COO ? CFO ? CTO ? I’ve done all of these, and still unsure, but we can look at it from a #Complex Adaptive Systems perspective to maybe obtain some additional insights to what the best approach would be for our own particular context. There are 2 features of CAS which I believe are particularly relevant for this topic: Path dependence and Affordances

– Path dependence

I think it’s useful to start with some Wikipedia references here:

Path dependence is when the decisions presented to people are dependent on previous decisions or experiences made in the past

In economics and the social sciences, path dependence refers to either the outcomes at a single point in time, or to long-run equilibria of a process. In common usage, the phrase implies either:

that “history matters”—a broad concept,[3] or

that predictable amplifications of small differences are a disproportionate cause of later circumstances, and, in the “strong” form, that this historical hang-over is inefficient.[4]

Wikipedia, https://en.wikipedia.org/wiki/Path_dependence

Complex systems have a history, and just because you have an opinion on the “optimal placement” of an Infosec function, not understanding or considering this history is going to lead to unintended consequences that you may or may not wish to acknowledge.

An example, I was once part of an Infosec team reporting under the CFO. So we were perceived literally as an extension of “Internal Audit”, and the way we communicated within our own departments largely resembled a “control-type language”, because that’s what the Finance department overall was about. That ended up reflecting in the way we did most of our work, up to and including how we managed risk registers. Suffice it to say, that our levels of cooperation with the CTO team weren’t that great. To them, we were the people with the “Compliance register” ready to tell them they can’t do something “because Compliance”. Even the more technical people hired to the team, are very quickly or eventually absorbed into this type of thinking because that’s what humans do. Culture changes us, whether we are conscious of this or not.

So considering Path dependence in your own context is key. In particular, understanding where the “need for security” is most urgent in the organisation. Some useful questions to think about this may be:

  • Do we have a rapid need of ensuring compliance to standards and get security under control, due to external pressures ? CFO or COO reporting may have merit.
  • Are we trying to operational and technical teams which feel security as part of their role identities, so a more gradual and ultimately sustainable approach is possible that would benefit from deep team integration and leverage of informal relationships to build the practice ? Then CTO reporting may have merit, provided the people doing the work speak the same language and aren’t considered “outsiders” ie just hiring Compliance-focused people for this context would likely not work very well.

– Affordances

Let’s again use Wikipedia to start us off:

Affordance is what the environment offers the individual. []

He defined an affordance as what the environment provides or furnishes the animal. Notably, Gibson compares an affordance with an ecological niche emphasizing the way niches characterize how an animal lives in its environment. The key to understanding affordance is that it is relational and characterizes the suitability of the environment to the observer, and so, depends on their current intentions and their capabilities

From Wikipedia, https://en.wikipedia.org/wiki/Affordance

So, affordance is what the environment offers the individual. this has huge implications to the effectiveness and efficiency of security teams. The issue of constraints also play a big role in our affordances. By constraints here, I don’t mean them in the sense of Goldratt’s “Theory of Constraints” which are mainly seen as “impediments to achievement of something” or as in the article “every system must have a constraint that limits it’s output”, but I mean it in the way Dave Snowden (from Cognitive Edge and in discipline of Applied Complexity) refers to them as something which contain, connects or exerts a force on something else.

For a practical example, there are many ways to implement security practices. We can think of them in isolation as standalone things we need teams to do, or we can think in a more integrated way and assess what practices the teams already perform that we could slightly modify to cover the security objectives we have. Both address the same problem, but one “constrains” the development process by introducing new practices, and the other “connects” the attainment of security objectives with existing practices the teams already perform.

Another aspect that significantly affect affordances are incentives and incentive management. If the CFO has an incentive of “0 internal audit points” and the CTO “delivery speed”, it’s already constraining the types of solutions we’ll see. Here, the greatest effect is the issue of “problem framing” vs “problem solving”. Because our “problem framing” may be seen as either one of “control” (when reporting to CFO) as opposed to one of “development agility” (when reporting to the CTO), it’s already significantly restricting the types of solutions we’ll be scanning for and considering, and the more or less political and social capital may need to be involved to settle the differences.

So questions that may be helpful to ask for considering the affordances provided to the Infosec team by the environment they operate in:

  • how would my ability to constrain or connect the practices with which we assure security be impacted by my reporting lines and potential mismatches in incentives ?
  • how much political capital would realistically have to be exerted to introduce any security transformation ?
  • in the current context and organisational pressures, what are the most urgent problems which need to be addressed ?

There’s no simple or universal answer to the question “Where should Infosec report to”. Whoever sells you that, is likely to be wanting to sell you something or have too much of a linear-causality mindset that is unlikely to be useful for long term and sustainable change, and that will keep fighting battles to the point of exhaustion and moving on. But if we were to be more strategic and considerate of our current contexts before we come to those decisions, I think our organisations would greatly benefit.

And on a last note, whatever structure you currently have, we need to stop thinking that they’re fixed in stone. What your company needs right now, may not be what it needs in 2-5 years time. Keeping options open and on-going and continued assessment of needs and efficacy of the current arrangements, is the best advice I could give.