A journey through organizational cyber resilience Part 2: Business continuity
Keeping a business up and running during a problem requires the right people for the job. When it comes to cyber resilience in tough times, a lot of things boil down to the human factor. We focused on this in the first article in this series, but it also makes a big difference for the second topic: business continuity. So how do you make sure your business processes and functions keep running during an outage?
Where cyber resilience meets business decisions
First of all, what is a business function? Information security managers and staff need to know because it is important that they are comfortable with the language of business. It’s just part of building and running a strong cybersecurity program. Part of this language includes knowing the nuances between business continuity, disaster recovery and ongoing operations. The IBM System Storage Business Continuity: Planning Guide Part 1 provides some very useful tips in section 1.1 showing these nuances. For work, you may need to be able to explain them. They could come in handy when you start to seek internal support for your cyber resilience efforts.
Essentially, a business function is the set of tasks that a service performs to produce a result. This is a very basic explanation, different for different jobs. But for our purposes, this is enough. A business process is often a set of chained tasks performed by people or equipment to produce a service or product.
Together with disaster recovery and other resilience strategies, good business continuity planning helps identify stakeholders. It also helps better position your group to respond to incidents that could impact your finances, brand, reputation and value.
Therefore, whatever cybersecurity framework you use, business continuity plays a key role. After all, you need to be fully aware of the services and products your business offers. In other words, while it’s your job to keep the network running and the data close at hand, it’s a good idea to know Why you have to do this. The answer is that you must continue to provide the service or product during an interruption.
Plans, plans and more plans for cyber resilience
If you don’t know where to start when it comes to the business continuity game, two great resources are NIST 800-34 Emergency Planning Guide for Federal Information Systems and ISO 22301: 2019. NIST 800-34 is very useful. It clarifies the differences between various distinct, but closely related, shots. These include business continuity plans, business continuity plans, crisis communication plans and more visible at the link level.
Maybe your organization can develop and execute all of the above plans. If so, your cyber-resilience posture is probably pretty strong, with the caveat: plans without testing are just dust-gathering documents. Therefore, you need to test your plans. And testing without concern for safety or culture means all you do is tick the boxes. Therefore, remember that plans are only the first step.
Process contingency strategies
Over the past year and a half, some of us have been fortunate enough to work from home. This is a unique example of a process contingency strategy. The business process has gone remotely due to an interruption.
Below are some of the more common process contingency strategies. Choosing the one that’s right for you and your business is a function of criticality, practicality, and risk tolerance.
Process transfer: As the name suggests, the process is transferred to another person or to another piece of equipment. You can transfer it internally, but don’t rule out a managed service provider either. This is where formal contracts and memoranda of understanding should already be in place.
Also, pro tip here: Along the cyber resilience journey, if you are relying on a third party, make sure you know what your priority is. Remember that an outage can impact more parties than you, and the third party you rely on can support many more. Any roadmap development for cyber resilience requires that you know what your resources are. The functions and service offerings of third parties fall into this category.
Alternative site: The process is carried out at another location. It should be noted in this case that another site may or may not be owned and operated by your organization. Again, you need to be aware of what your contractual agreements are with third parties.
Remote work: There is a nuanced difference here between the alternative site and remote work. The perfect example for many is working from home. After all, you’re not really working on another site in this case.
Follow the sun: You’ll see this strategy for organizations that normally have a global footprint. This does not apply to all businesses, of course. But it is useful for the resources of large companies spread around the world. In the most basic form, the sun tracking model means that offices in different time zones pass processes between them. It sounds very convenient in theory, but in practice it can be a bit more difficult. After all, different regions need to manage not only their local processes, but also those of the region that has been disrupted. This may require additional coffee makers.
Depending on your business model, you may be able to come up with additional contingency strategies for your processes, but practicality should be part of your decision making. A small business, for example, may not be able to transfer a process because it has limited staff. This is where succession planning comes in. But what you should start to notice is that there are a lot of pieces moving here and more to come on the cyber resilience journey.
Putting the pieces of the cyber resilience puzzle together
In the next article in this series, we’ll talk about disaster recovery and identifying interdependencies. Disaster recovery is an interesting topic because of the cloud. In short, much of the literature and practice surrounding disaster recovery was written in the days of data centers and colocation sites. So stop by next time to see how the cloud is changing the disaster recovery discussion.