3. Put the Right Security Governance Model in Place

I’ve seen three basic types of security governance models: centralized, decentralized, and matrixed. Which one is optimal? Generally, the model should align with the way that the business itself is governed and/or the way it provides IT services. For example, if the business has subsidiaries each operating their own IT fiefdoms, security cannot be fully centralized.

Many medium and large, complex organizations are tending to become more decentralized in the age of the digital business. To fulfill enterprise security requirements, they tend to need some form of matrixed security governance. For example, a CISO might provide overall security leadership, while operations are farmed out to IT groups in various business units. The CISO position itself could report to IT, or it could report to another executive business function such as the CEO or the Chief Risk Officer (CRO). There are advantages and disadvantages either way, and the right answer must be aligned with the business and IT culture and any operational or regulatory requirements.

Friction with business units can result from having the wrong security governance model, and security-related activities become more difficult to accomplish.

As we’ll see in the section “Understand and Apply the Optimal Security Governance Model,” a matrixed model is often the best solution for a complex organization, such as a multinational company. However, operating matrixed security governance requires more sophisticated (or mature) security management committee structures, cross-functional alignment, and security policies. Without the maturity, matrixed governance may fail to govern.

In Chapter 7, we identify digital business and cloud-first strategies as trends that tend to weaken business unit engagement with traditionally minded IT departments. The security organization may be tightly embedded under an IT department riven by technical debt and hollowed out by shadow IT. Business units are rapidly adopting cloud solutions, and the overall IT environment is becoming more decentralized. Cybersecurity still is, and should be, a management concern, but the security department may have no room to maneuver because of any (or all) of these reasons:

As described in Chapter 7’s section “Discern the IT Strategy and Align the Security Road Map to IT,” security leaders can take advantage of the inherently cross-functional nature of security to work with IT to develop IT and security strategy, align security priorities with strategic platforms, and engage with LOB initiatives.

However, the security governance function may need a reset (see the section “Reset (or Define) Security Governance” in this chapter).

Even when business leaders are aware of cybersecurity issues, they are often subject to perverse security incentives. It's possible for business executives to place such strong demands on staff for secure outcomes that they create a perverse incentive for insecure behavior. A former financial services company CISO we interviewed (who prefers to remain anonymous) recalled that “The business and security staff at my employer from the Chief Counsel on down were more afraid of the CEO and the Board reaction to regulatory reports than they were of breaking the law.”

“Ironically,” our ex-CISO colleague continued, “I don’t think the executives were even conscious that they were pushing staff towards making false reports. As far as they were concerned, they’d put security first. They’d granted the full budget we asked for.”

This is a tough challenge! More alignment in top-level thinking will probably be needed to pull off a successful security governance reset. Security leaders who choose to stick around and face the challenge can take a leaf out of the “crucial conversations”¹ book I keep out on my office reading stack; it provides useful scripts to prepare for difficult discussions. It could also be helpful to engage an executive change management consultant or another senior mediator.

In a centralized security governance model, one person or department makes all the important decisions, controls operations, resolves disputes, and sets the strategy and the budget for security. Responsibilities can be delegated but managers still report directly to a single leader who serves as a central authority. Centralized governance with strict hierarchy is typical of military and often civilian government and some corporate organizations.

In the decentralized model, multiple organizational units operate security programs independently. This is common among multinational organizations or businesses that have grown by acquisition. Each organizational unit in this model has its own security team.

The decentralized model doesn’t preclude the business from requiring units to coordinate on developing shared services or from following some common standards. But if a decentralized organization has a CISO at the enterprise level, this CISO will tend to be in a weak position. Don’t be fooled by the “Group CISO” title you sometimes see in this case. In the decentralized model, each line of business (LOB) manages IT and security according to its own needs.

If we were to imagine a continuum between highly centralized and decentralized security governance models, we wouldn’t have to go too far toward either extreme before seeing issues and disadvantages.

Too centralized means rules for security governance may be too rigid. Some LOBs need more flexibility and, in the end, may not cooperate with security strictures. Too decentralized and LOBs will likely duplicate security efforts (or make inadequate efforts) creating inconsistent security controls that make it hard for the business to respond coherently to common threats or compliance requirements.

Given the trade-offs between centralized and decentralized models, organizations often turn to the matrix model in search of a sweet spot.

Matrix security governance structures can coordinate the management of cybersecurity for very large organizations. Figure 3-3 illustrates an example that operates governance at four levels.

Let’s decompose how the matrix works at each level.

Lines of business and IT services: At the lowest level, LOBs or regions in Figure 3-3 run their own IT functions; however, some commoditized services such as email systems and endpoint anti-malware may be shared. LOBs and regions may also use cloud computing services from diverse vendors.

More strategically in the matrix model, local business units can plan for future iterations of the applications and shared services they need. They may share in the costs for shared services. There may be representatives from the CISO function on liaison to the business units, or business unit staff may have a dotted line responsibility to the Group CISO.

Cross-functional working groups: Moving up a level, matrixed organizations typically have an enterprise CISO and CIO function, for example, a “Group CISO.” However, larger business units beneath them may also have CISOs. Note that the diagram is drawn to put the Group CISO and CIO together for graphical convenience and is not meant to suggest this reporting structure is universal. Exact titles vary between companies, as do reporting structures.

The Group CISO/CIO organizations provision and protect the shared services. They continually interact with the local functions to enable, approve, or coach the lower echelon security management. The Group CIO manages the architecture and operations for shared services, and either the CIO or CISO manages security services or security components of shared IT services.

Executive committees: The Group CIO and CISO also interact on a peer-to-peer basis with the heads of business administration, that is, HR, legal, and finance, to address share budgeting and procurement processes. Cross-functional working groups may exist permanently or form temporarily to undertake major risk assessments, approve changes, or develop new architectures. The executive committees report up to the Board and executive levels. For complex organizations - such as multinational corporations with subsidiary legal entities - multiple layers of reporting may be required.

As with the centralized governance model a security team or department reports to the CISO. But in the matrixed model, some members of the team may work for other functions but have “dotted line” reporting to the CISO.

In general, matrix structures require well-articulated cross-functional and cross-divisional roles and working groups, processes, accountabilities, and lines of communication and control. Key questions: Is the matrix structure well designed or not? Does it suit the organization’s culture?

Operating a matrix organization is challenging precisely because of the cross-functional dimensions. Research suggests that most cross-functional teams are dysfunctional.² Why then do so many organizations adopt the matrix model and then struggle with it? The answer: Once an organization gets to a certain size, or a certain level of complexity, there may not be an alternative. Perhaps, for large or complex organizations, one might repurpose an old joke about democracy: “Cross-functional governance is the worst form of governance there is except for all the others.”

Another interesting point: Many matrix governance structures are not pure; they don’t look like those in Figure 3-3. Organizations often have hybrid or composite governance models. An organization with composite governance could be decentralized as a whole but contain one or more large lines of business that operate in a centralized or matrixed manner. Each LOB might be large enough to form an enterprise. Corporate conglomerates and large national or state governments often have composite governance.

Occasionally businesses just decide “we’re going to have centralized, decentralized, or matrixed IT or security” and then have a big reorganization. More often, one of those structures simply results from how lines of authority and decision rights are allocated over time. Nevertheless, understanding which governance structure a business has vs. which structure it should – perhaps – have is a useful thought exercise.

Security leaders rarely if ever get to choose the governance model themselves, but they should always be ready to discuss the matter intelligently. Which is the right security governance model: centralized, decentralized, or matrixed?

Most small organizations can use a centralized model and most large ones should make some attempt at formal or informal matrixed governance. But it would be a cop out to stop at that, because there’s much room for variance with different businesses. The decision tree in Figure 3-6 provides a more nuanced answer than “small equals centralized, larger equals matrixed” by using criteria based on the structure and maturity of the business.

Per the decision tree, a small organization or a large one with a hierarchical and relatively homogeneous structure (and culture) might go the centralized route for greater control and efficiency. A larger, more complex business tends toward decentralization; however, if management seeks to drive greater consistency and control, it can push toward the matrixed model as IT and security programs gain maturity. Any decentralized security arrangements should be buttressed with clear accountability for all security leadership and operations functions.

The business should specify the security program mission and define the program’s lines of authority and decision rights in a security charter document. The security charter document contains the business’s definition of security and of the security program. It must also identify how the security organization coordinates with the business and how it relates to audit, compliance, risk management, and other functions.

The charter should be a short, plain language document intended for broad consumption. It should be signed by the organization’s CEO or equivalent position to give it the gravitas to serve as the business mandate and the foundation component of the security program. It should define security for the business by describing the security program’s mission, operating principles, governance, and reporting structure. For example, the security program’s mission statement could describe security objectives including confidentiality, integrity, availability, safety, and privacy in terms of the business’s specific high-level goals and requirements. The charter should also reference core governance principles; the following is a short sample

Security is everybody’s business according to their role. While avoiding specific job titles, the charter and subordinate policy documents should spell out the accountabilities and responsibilities for cybersecurity for general business roles such as

The charter should call for establishing a cross-functional coordinating committee (aka security steering committee) as a security governance forum for business, IT, and security leaders to authorize and oversee major security projects, budgets, and changes. The charter should also define the security policy hierarchy. Few or no details are required in the charter itself other than basic scoping of the committee's basic makeup and purpose.

The charter explicitly defines the security governance model. It can specify whether the organization shall have a security leader with the CISO title. It can also specify where the CISO or security leader reports and the scope of responsibilities. The following guidance is intended especially for businesses that have formally appointed a CISO in a corporate officer position.

Per Chapter 2’s section on the “Head of Security or CISO,” the “CISO” title sets an expectation that the security leader can represent the security program to the Board of Directors, external regulators, and other stakeholders as well as sit in on top business and IT leader meetings as a peer. Where a security leader, or CISO, reports in the business hierarchy is also an indicator of whether he or she is empowered to drive a cybersecurity program for the business.

In my experience, most CISOs – at least half – report to the CIO. Strong arguments can be made that this is a good thing, for if the CISO is responsible for IT security, shouldn’t the position associate closely with IT? However, many security experts argue against putting the CISO too low in the organization chart or against creating a potential conflict of interest between security and a CIO whose performance objectives, such as application time to market, may run counter to security. Experts with this view advocate having the CISO report to a senior executive outside of IT – such as the CRO or CEO (aka CXO).

For the purposes of Rational Cybersecurity, there isn’t one right answer. Suppose the Board considers this question: “What’s more important for our Cybersecurity? Operational effectiveness and Security-to-IT alignment, or strengthening security by making it an independent function?” Directors of highly regulated organizations tend to have separation of duty requirements and prefer CXO reporting, whereas organizations under less security pressure are more likely to choose CIO reporting. Depending on the business’s cybersecurity maturity level, management style, and executive personalities, either reporting structure can work, with caveats.

CIO reporting structure caveats: In most organizations where the CISO is directly responsible for conducting or overseeing IT security operations, one of our CISO contributors observed: “As the CISO, it is critical to be no more than one level removed from the Board (or CEO) and to have my name on the security section of the Corporate Board Reports.” Without that visibility, and the opportunity to present important security initiatives and budgets to executives, the CISO position might be too weak to conform to the expectations created internally and externally by using the “CISO” title.

Also, note that empowering an independent internal audit function, whether or not it is required by regulations, may provide an adequate check and balance on the CIO even though the CISO reports to IT.

Change is the only constant: More than one CISO I interviewed noted: Not only does the optimal reporting structure depend on hard-to-quantify management style factors, these factors change frequently.

There’s clearly much more to say on the subject, and if you’re interested all three authors of the “CISO Desk Reference Guide” opine on the role and reporting considerations right in their first Chapter - “The CISO”.⁴

A large enterprise can establish a dedicated steering committee for security-related operations, projects, and business decisions. However, mid-size organization may reasonably combine the function into a general IT leadership committee as one of its recurring work topics. We’ll refer to the coordinating function generically as a “steering committee.” The level of security pressure is another factor determining whether to have a dedicated committee: In 2017 and 2018, I consulted for a US-based systemically important financial market utility (SIFMU) with just a few hundred staff but a regulatory requirement to focus heavily on security at the highest levels of the business.

The steering committee authorizes and at a high level can direct security projects, oversee security policy, and control the security organization structure. The heavy hitters among the leadership – those holding CISO, CIO, Chief Risk/Privacy/Compliance offices, legal, HR, and third-party management positions (or roles, in a smaller business) – should be represented on the committee. So should key LOB leaders such as manufacturing, sales, distribution, and operations. The business and security executives themselves can attend or appoint leaders with signoff authority delegated on their behalf. (In larger businesses, major LOBs may have their own business information security officers (BISOs) as well as finance and legal representatives on the steering committee.)

The steering committee should meet approximately monthly. The sponsor and/or chairperson should have administrative support to maintain a formal agenda, track issues, manage any subcommittees or activities that require attention between meetings, and publish minutes and reports. Typical activities are

What I’ll refer to generically as the “risk management forum” could be chartered as a committee dedicated to information risk. The CISO or a Risk Manager on the CISO’s staff can chair this type of forum.

However, the forum may instead be part of an enterprise risk management (ERM) program. ERM covers financial, operational, market, competitive, and other risks as well as information risk which rolls up into it. An ERM forum doesn’t fall under information security governance, but the CISO (or a delegate) should be a member or participant.

Financial services businesses (depending on size and jurisdictions) tend to require ERM programs. Many other kinds of businesses – whether larger or small – have corporate social responsibility, ethics, and/or compliance committees to monitor enterprise risks at the highest level. Any of these executive committees (or a new group) could become the risk management forum. The forum:

Chapter 5 contains additional guidance on the activities of the risk management forum.

Standing governance forums such as the security steering committee and the risk management forum are necessary and important. As the security program matures, especially in a larger enterprise with matrixed security governance, more and more issues can require regular agenda time.

Security leaders may be tempted to establish multiple standing subcommittees of the main steering committee or risk management forum but should be careful not to overdo it. Digital business demands more agility from businesses. Keeping standing security forums lean helps ensure that security doesn’t get in the way of reasonable business initiatives through overly bureaucratic processes. Rather, the business can use existing security, IT, or corporate governance processes to promote collaboration between security business leaders and oversee security projects. These can include

The term “policy” in security often conflates four or five types of control documents: a top-level security “policy” and standards, guidelines, processes, and procedure documents. Figure 3-7 displays the relationship and hierarchy among those types of documents.

Each control document or type of “policy” at a lower level of the hierarchy must operate within the permitted scope of any related higher-level documents. For example, the organization’s highest-level security policy may operate under the security charter. More detailed policy or standard documents set requirements for topics such as acceptable use, access, network security, encryption, and so on. Guideline documents and processes provide instructions. In general, the higher-level documents specify the required business security outcomes (the “what”) and subordinate documents specify the ways and means (the “how”).

Businesses should also articulate guiding principles, scope, and purpose in the top-level policies (the “why”) to help management and staff understand the policies’ intent in all situations. Although top-level policies should not contain promises of future improvements or plans, guiding principles expressed in the policies can indicate future direction in a general manner where appropriate. Table 3-1 identifies (in general) which kinds of security and business leaders own, are affected by, and must be aligned with each type of policy document.