From governance comes everything else. It would be reasonable if this journey in organizational resilience started with the governance theme. In fact, many important standards or cybersecurity frameworks begin with policy development. For example:

  • NIST SP 800-34: The first step in contingency planning is policy development.
  • NIST Cybersecurity Framework: Part of the first step, Identify, is the need to establish policies that outline roles and responsibilities.
  • ISO 22301 and ISO 27001: Right after understanding your organization, the next section is leadership and policy development.

Why is governance so important to a resilience program? Well, start with this question: what are two requirements for law to apply? Jurisdiction and enforcement. If you have jurisdiction, but no way to enforce it, you have a bunch of paper. If you have enforcement but no jurisdiction, you are running rogue.

A strong, well-thought-out and actionable governance program sets your organizational resilience efforts in line. It gives you boundaries and allows you to manage the program.

Therefore, time to go back to an old favorite from Sydney Finkelstein: why these three questions can solve any problem.

  1. Are you really willing to change what you have been doing?
  2. Can you think of a better strategy or idea than the status quo?
  3. Can you execute on your chosen solution?

Keep these questions in mind as we examine governance and policy development issues. And for all you chief information security officers out there, this is a good time to remember the importance of soft skills, budget impacts and knowing your business. Your success depends on it.

Governance is meant to be difficult

Imagine for a moment you are the information security leader of a large enterprise that has been growing over time, both on its own and through mergers and acquisitions. Throughout this process —as business was on fire — something happened. Your information security management practices went off the rails. The entire process became too big to manage and every business unit was off doing its own thing.

If you are part of a large enterprise, does this scenario sound familiar? It likely does.

Why is that? Well, it comes down to resource management and risk appetite. Both of which likely have been neglected or have changed over time. However, the boundaries and means to manage — think jurisdiction and enforcement — have not.

This is why the first two steps of any cybersecurity organizational resilience roadmap are identifying resources and defining your risk posture and seeing that performing these two steps is not a one-time affair.  Quite the contrary. They are ongoing tasks that will inform your governance and policy update. For example, if you really want to go best practice, any major change in how your business works should trigger an automatic review of your resilience program’s governance and policies.

Centralized or federated?

The two steps above help get you in the right frame of mind and find your own borders. For example, does your organizational resilience program bleed into your privacy program? It may, and that may not always be a bad thing. Rather, it is a matter of deciding what is right for your case, which is why governance, policy development and enforcement are difficult.

You have to ask yourself hard questions. For example, will you have a centralized resilience program? That means there is a dedicated team that runs the program and will be held accountable by the C-suite if something goes wrong. Or, will the program be federated? In this case, resilience personnel will be embedded within business units. Those units will be held accountable for resilience tasks.

Let us get one thing straight here: there is no right answer. Rather, there is only the right answer for you.

And that is why if you start going down the road of cookie-cutter governance and policy development without making adjustments for your case, everything else downstream — such as your business continuity, disaster recovery, crisis management and testing and training — will be muddy.

That is why, short of a major change in how your group works, your organizational resilience governance should be pretty rigid. These are your guiding principles, your North Star. Conversely, your resilience practices (BC, DR, CM, etc.) can change to adapt with the times.

Developing the right model for your organization

To get a good sense of whether your organizational resilience governance is in good shape, some self-assessment is required. Ask yourself these questions:

  1. Do you truly understand your risk posture?
  2. Are you able to stress test your program and systems, on a regular basis and often?
  3. Can your program and the systems that go with it meet today’s challenges and tomorrow’s?
  4. Are your teams serious about a resilience or cybersecurity-minded culture?
  5. Are the right resources in place for success?

Go back to the questions about solving any problem. Between these eight questions, you have everything you need to create your governance model. Why? Because, taken together, answers to these questions are the Rosetta Stone to understanding your organization. These questions help you go deep, clearing the muddy waters of who does what, how everybody is working, what is missing and what needs to be done.

Back to the example above: if you have business units with different incident response plans or resilience efforts spread across teams that do not interact with each other, you are walking into a tangled mess after an incident.

What outcomes should governance seek?

Imagine your organizational resilience program governed in the following way:

  1. The Policy: Gives you purpose, or the why.
  2. The Standard: Gives you context, or the what.
  3. The Procedure: Gives you direction, or the how.
  4. The Guideline: Gives you comfort, or gives you light when you fall into darkness.

With each step, you get more granular in detail, but the top needs to be sound. Otherwise, the entire program will come down crashing in on itself. That is why, within all of the components listed above, you must clearly identify who holds responsibility and accountability for all associated tasks. To tie back to the beginning, this is your jurisdiction and enforcement roadmap. And if you recall from the crisis management team, resilience is most certainly a team game. That’s why knowing your roles and boundaries are critical to success.

In closing, don’t be scared if governance looks like a daunting task. It is, and is often a root of your grief. If you get it totally off the mark, the downstream impacts can be terrible and you can be sure there will be a lot of finger-pointing. But there is a foolproof way to ensure your organizational resilience governance model, and related practices, are working. We’ll examine that in the next piece: testing and training.

More from Risk Management

Are we getting better at quantifying risk management?

4 min read - As cyber threats grow more sophisticated and pervasive, the need for effective risk management has never been greater. The challenge lies not only in defining risk mitigation strategy but also in quantifying risk in ways that resonate with business leaders. The ability to translate complex technical risks into understandable and actionable business terms has become a crucial component of securing the necessary resources for cybersecurity programs.What approach do companies use today for cyber risk quantification? And how has cyber risk…

Cybersecurity Awareness Month: Cybersecurity awareness for developers

3 min read - It's the 21st annual Cybersecurity Awareness Month, and we’re covering many different angles to help organizations manage their cybersecurity challenges. In this mini-series of articles, we’re focusing on specific job roles outside of cybersecurity and how their teams approach security.For developers, cybersecurity has historically been a love-hate issue. The common school of thought is that coders are frustrated with having to tailor their work to fit within cybersecurity rules. However, many companies are embracing a security-first approach, and some developers…

Spooky action: Phantom domains create hijackable hyperlinks

4 min read - According to a recent paper published at the 2024 Web Conference, so-called "phantom domains" make it possible for malicious actors to hijack hyperlinks and exploit users' trust in familiar websites.The research defines phantom domains as active links to dot-com domains that have never been registered.Here's what enterprises need to know about how phantom domains emerge, the potential risks they represent and what they can do to disrupt phantom attacks. There are two common types of phantom domains: Errors and placeholders.Domain errorsErrors…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today