This article will answer the following questions:

  • What are the most common models of security leadership?
  • Which model is the best match for my company?
  • What are the benefits of using a centralised model?
  • What is the main advantage of a decentralized model?
  • From what angles should a cybersecurity manager approach cybersecurity management?
  • How does a cybersecurity manager get the authority to execute the security policy?
  • Why do I need to get my cybersecurity policy approved by the company board?
  • What should I include in my top-level security policy?
  • Who owns what cybersecurity problem?
  • Who do I involve in policy creation?
  • Should an employee be punished for violating the security policy?

The Cyber Security Manager Part III: Security Leadership

Cybersecurity managers must understand how company leadership is organised around security. They have to understand how the company leadership structure works and recognise that security is everyone’s concern—not a separate function relegated to a select few. Of course, in larger companies, it’s natural to hire specialists to work in various security functions. But in many companies, the cybersecurity manager can be a standalone role or even a part-time employee.

Security Leadership Models

Security leadership is, first, about who is making the calls. In principle, that means there has to be a structure in place for decision-making around security issues. In reality, what often happens is that a cybersecurity manager starts with a company, and everybody rushes in with the problems that nobody else was able to solve. The underlying thought seems to be that if it’s nobody else’s problem, it’s probably security’s problem.

There are two ways to handle security leadership more effectively. The first model of security leadership is centralised management. The centralised model is when you have one person or committee with oversight and approval of all security responsibilities in the company. It’s a one-stop shop.

The second is the decentralised model. This is where a number of different people in various departments within the company each make their own decisions about security based on the needs of their particular area.

Larger corporations might use a mix of both models. A company with many subsidiaries, for instance might find it impossible to run security in all of them from a single centralised security team. People working in the subsidiaries probably take instruction from headquarters hundreds of miles away with a grain of salt. They might complain that the home office staff doesn’t set foot in their facility or do the hard work, that they just issue the rules. Frankly, quite often, the staff in subsidiaries don’t even know who owns their shares, let alone who is their counterpart in corporate security matters! In those cases, it might be better to use a hybrid model—employ an on-site security champion or an agent who learns and understands the local operation but who is also cooperating with the centralised function.

We worked with a company that had about 40,000 employees in around seventy standalone subsidiaries and three independent business divisions. They set up a centralised security function for managing all of the security in the entire organisation. They had around five people in the centralised function and then a large number of roles doing different, separate security tasks around the different locations. There were working groups for different security issues; for example, health and safety alone had more than seventy people working together. Similarly, security in IT employed more than a handful of full-time professionals. Of course, they also held a lot of conference calls and virtual meetings where people could discuss things and follow up with programmes and policies.

In a centralised model, the advantage is that you have all the decision-making power in one place. They can easily get policies drafted and accepted with the headquarter executives. It’s fast to make decisions, and you don’t suffer from the confusion that can set in when ten different people are doing things their own way in separate parts of the organisation. From the company level, the centralised model looks more organised, and that’s a cybersecurity manager’s dream—to have all things well organised.

The disadvantage of the centralised model is that those sitting outside of that central function, far away in a branch or in a subsidiary in a different country, don’t have much contact with the central security function. They’re left pretty much by themselves with little support. The policies, procedures, and guidelines that come from the ivory tower might be good for their part of business or totally unsuitable, but once policies are issued exceptions, it will cause trouble. This can create friction. Plus, dealing with security is time consuming. The time the home office spends doing centralised security functions takes away time and focus from what they should be doing—running and growing the business.

The advantage of a decentralised model is that the authority and discretionary decision-making power given to different branches of the organisation allows them to create the best processes for their unique situation and circumstances. There is no omnipotent ivory tower issuing policies that don’t make sense for their branch. Perhaps, the headquarters just issues a high-level policy that the rest of the cybersecurity has to be managed so and so. Call it a meta-level policy that sets a requirement for subsidiaries to build their own security management systems. The disadvantage is, of course, that policies can end up being wildly inconsistent, and security standards may vary from one location to the next.

One detail we like in the decentralised model is that it allows things to get done, and it is very adaptable. The branches know what they need, so they do it. In contrast, people in the ivory tower seldom get their hands dirty. When they do try to go hands-on, it’s often a disaster. Because they don’t know exactly what the branches do, the people from HQ may end up creating misguided or inefficient policies.

Whichever option you decide to go with, centralised or decentralised, try to consider how to take the best of both approaches. The old wisdom in Zen is that best way to keep a herd of sheep in control is to let them loose on the pasture but keep a vigilant eye on them. You will need to give a certain amount of localised freedoms, but you also need to be the person who makes the final call in all things that affect the whole enterprise.

Security Leadership Dimensions

The cybersecurity manager should look at security leadership from several angles—leadership is about many things, not just about managing security matters.

This is the high-level leadership framework that we’ve used successfully in many of our customer engagements. It is easily understood by high-level management and covers most of the cybersecurity leadership issues from a management point of view.

At the policy level, a cybersecurity manager would make sure that all dimensions of cybersecurity that are relevant are governed through a suitable policy. From a people perspective, he should engage the teams, governance models and executives who are key in making the policies happen. Then those people, and their security responsibilities would be included in the relevant policies and approved by the top management. From a systems perspective, the cybersecurity manager would see that this cybersecurity governance structure is enforced by security technologies and that the key technologies will be included in the policy framework. Finally, he would see that third parties, like vendors and service providers, are covered through requirements in their contracts.

Support Through Policies

Policies are important to the cybersecurity manager. Without security policies approved by top management, the cybersecurity manager has no authority over anybody or any issue in the company. Without management authorisation and support, the security manager is just another employee.

The highest-level security policy in the company needs to explicitly state the responsibilities and authorisations of the cybersecurity manager’s role, goals for cybersecurity, and management support for it. The policy should define things like it’s scope, purpose and goals. The scope describes all the things that are governed under the policy. The goal is the purpose and objective of the policy—it has to make sense and has to have a reason to be there. Each policy has to be for somebody and about somebody. The highest-level policy for cybersecurity might just state that cybersecurity is essential for protection, and it supports the business goals of the company.

The “what” part is the actual requirements of a policy—usually called policy requirements and stated in plain English. These must be stated clearly in the policy so that anybody can understand them, even someone who doesn’t speak security lingo. It’s best to make the highest-level policy short and understandable, a statement from the management more than an operational document with a lot of instructions and requirements.

Get the Right Approval

Once the cybersecurity manager has formulated a policy, it needs to be accepted by an appropriate level of management in the company. The highest layer is the board of directors, the biggest big shots. They represent the shareholders and sit above the top management of the company. To get a policy accepted by the board, the cybersecurity manager has to work with the CEO and management team to get the policy on the agenda for the board to review it.

The board’s responsibilities include oversight on the largest risks in the company and oversight on compliance issues. For example, in some countries, it’s mandatory for financial organisations to have board approval for risk management policies. The good thing about having such a document accepted at the board level is that management will be obligated to follow it. Obviously, not many policies will ever be accepted at the board level, and seeking acceptance from that body should be expected to be slow. Boards meet only so often.

Top-Level Policy

The cybersecurity manager will also work with the layer below the board, operative management. This is the senior management team, the C-level executives, and the CEO. The cybersecurity manager is not running every policy for every risk by all of these people; most companies have one overall information security policy document. It’s just a few pages long, stating what the company wants to achieve with security, what’s the main goal, who runs the show with regard to information security, and who’s responsible in each department—the policy should state a function or role but not the name of the person.

The information security policy document should also include some general guidelines or goals in different areas. For example, it may state that the company wants to support a new product line and that a certain position title within the organisation will be responsible. “The VP of Software Design will be responsible for this goal.” The document should then provide an outline of where security belongs and who is responsible for it in different parts of the organisation. Finally, the information security policy document should state that not following the policies may be grounds for disciplinary action. It should be signed by management or the CEO.

Below the top-level security policy document, there are additional, more specific policies, and these are much more detailed. These include things like HR policy, HR security policy, and IT security policy. There may be very detailed policies about each function. Usually, the heads of those functions have the authority to approve and sign them. Sometimes a sign-off by another member of the management team may be required.

Who Owns It?

Defining who makes the calls may be the most important part of the policy. For example, if a cyberattack hits the help desk, there might be uncertainty about what role and what authority the person leading that team has. Let’s say there’s a spam campaign with phishing messages and malware hits, so people are calling the help desk. Who is responsible for escalating things in that process. Is it the security manager or the help desk team leader?

For most of us, it’s evidently the help desk team leader who should handle this scenario, and that department head should have a policy-defining chain of command. A lot of people in the organisation, though, might think it’s the security manager and would call the cybersecurity manager directly. Quite often, the security manager makes the mistake of starting to sort out the issue because someone called in to ask for help. That’s not the proper way to do it, usually. The cybersecurity manager should direct everyone to the help desk and say, “We will work with the help desk to address this threat. But the help desk leader is in charge.” If it’s a security incident in a large company, the company may have a dedicated incident management team who can take over the investigation and remediation of such incidents. But it all begins with the business function that initially noticed the problem. It’s their job to know when things need to be escalated further.

To make leadership decision-making responsibilities clear, a small company might have weekly or even monthly meetings for policy issues, then present them to management when necessary, while a global company needs a lot more structure.

Leadership decisions and policymaking tend to be slow-paced. The cybersecurity manager should be prepared to reserve a meeting, have it in two weeks, help write out a draft of the policy, go and have it accepted, announce it to people, train the staff, and then implement the policy. This process can take months.

Occasionally, decisions get made faster, like when a disaster strikes and the cybersecurity manager needs to fix something immediately. There’s no time to involve any managers. This layer also has to be defined within security leadership. If there’s a service desk, and the company is hit with a cyberattack that makes people call the desk, they should have the authority to handle the issue immediately without having to escalate it and wait for decisions from above.

There is no time for management meetings for very urgent issues. For example, there should be no waiting when it comes to phishing campaigns. If the service desk, IT operations or other departments under the pressure don’t have the authorisation, they should take the risk to just get it handled. Ideally, these types of urgent incidents should be provided for in written policies and incident management procedures.

What Else to Include

The cybersecurity manager should involve leadership in policy creation whenever possible. Ideally, the cybersecurity manager wouldn’t actually be writing the policy, just supporting the creation of it. That means when helping a department create a policy—like HR security or IT security. Quite often, however, it ends up that the cybersecurity manager does actually write some or all of the policy for the department, and then the department head comments on it and revises it as needed.

Responsibility should be part of every policy. If there is a policy that doesn’t state who it’s for and who will be acting within its scope, it’s just a paper that doesn’t affect anybody. Nobody needs to read it, and nobody needs to adhere to it. The responsible parties must be spelled out in the policy.

Most companies take security issues very seriously. There might be a general non-compliance clause that states if employees don’t accept and follow the policies, they might be punished somehow. We’ve seen companies go so far as to take away the computer from an employee for a period of time if they fail to follow a policy that requires employees not clicking phishing links. It sends a clear message: pay attention and follow the policies. The harshest way to get the word out that the company takes security seriously is to fire a person for a security violation, and it usually happens after a huge mistake is made. We don’t say that punishment is the appropriate reaction to everything, but the possibility to use it has to be present. Use it sparingly, though—reward is also a powerful tool.

Send check result to email