Security Governance (Part 2): Operating the Matrix
At the root of many consulting engagements we find a security governance problem. Last week, in Part 1 of this series, I described the centralized, decentralized and matrixed primitives of security governance. I published the matrixed security governance diagram shown below as a example of one that would serve many large, distributed organizations well. Although neither this nor any other single model is best for everyone, the principles we’re going to cover are universally helpful..
The easiest way to understand how the matrix works is to describe it from the bottom up. Down there, lines of businesses are making, selling and delivering goods and services using their information and computing assets. They’re patching, fixing, changing and using their hardware and software. Often, they take advantage of shared services such as a network operations center, or corporate email and collaboration system. For a day in the life of the LOB, see below….
Do LOBs have to use the shared services? Some will be mandatory, others optional. Perhaps all the shared services are optional but LOBs have financial incentives to use them. That kind of thing has to get worked out at the group level, between Group Finance and Group IT, for example, or directly among the LOBs’ executives higher up in the matrix. At the group level, architectures get written, policies set, risk assessments made, big contracts and hires get done…take a look.
Expect creative tension about priorities, changes and allocating resources at the group level and among the LOBs. The matrix is constantly changing and the organization needs its checks and balances. Issues get escalated up the ladder by the LOB executives all the way to the C-Suites and resolved through informal or regular interactions. But ad hoc isn’t always good enough. Risk, compliance and audit issues need to be managed on an ongoing basis by executive committees and/or chief risk officers. Otherwise, how can security get a fair hearing?
Not that the typical CEO or Board member will (or should have to) get deep into the details of why IT needs to shut down the production line to roll out a new series of patches, or why its a bad idea to let all the outsourced sales teams get full VPN access. IT security may only get 15 minutes on CEO’s agenda every so often and every one of those minutes has to count.
That’s where the executive committees come in. These committees curate all the important data about important issues for the executives. Its not just about IT; the risk committee (or risk council) deals with Enterprise Risk Management (ERM). But there’s an IT risk management component to ERM, and a good council meets regularly for some deeper dives to maintain a dashboard of the top issues from the risk register, outline decisions that need to be made, explain the alternatives and have the drill down data handy. And once the committee, or the C-level executives themselves, have decided an issue, the risk council tracks how the decision gets put in effect through policy and other controls.
The risk council also works with its sister executive committees under the eye of the C-Suite. Compliance injects risks to the risk council, or listens to the risk council’s take on how a new set of controls can solve a regulatory problem. Internal audit provides oversight over IT, finance and other areas and it reports on the risk and compliance issues that it find to top management as well.
Bottom line
When all the moving parts are working smoothly enough, you have effective security governance. In coming posts we’ll address other issues in the matrix, such as who gets seats on the executive committees, where does the CISO report in the hierarchy and more.
NEXT – Five Essential Questions for Matrix Security Governance