<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">
Curious about how StrongDM works? 🤔 Learn more here!
Close icon
Search bar icon

Best Practices when Creating a Business Continuity Policy

StrongDM manages and audits access to infrastructure.
  • Role-based, attribute-based, & just-in-time access to infrastructure
  • Connect any person or service to any infrastructure, anywhere
  • Logging like you've never seen

A business continuity policy is a critical part of your SOC 2 preparation. According to the Federal Emergency Management Agency (FEMA), nearly 40 percent of small businesses never reopen their doors after a disaster.

For small businesses, in particular, it can be difficult to return to normalcy after a significant disruption. Most companies have insurance and emergency funds, but those won’t protect you from failure to provide business functions at an acceptable level to your customers.

A Business Continuity Policy (BCP) is critical to your information security program and defines the critical steps your employees need to keep the business processes running after a disruptive event. The plan addresses the critical infrastructure, backup plans, emergency contacts and detailed recovery procedures you need to address potential threats.

Here are some best practices you should consider when writing your business continuity plan:

1. Don’t just rely on a SaaS vendor

Yes, it is possible to migrate all your infrastructure and other critical assets to SaaS. But by doing so, you inherit whatever controls the SaaS vendor has in place, and shift responsibility entirely onto them during a failure. However, you are still ultimately responsible for creating a failover plan and having redundant solutions in place.

If you are going to rely on SaaS vendors, you need to be cautious about what is outlined in your contract with them. Here are a few questions to ask:

  • What happens if the SaaS systems or networks stop working?
  • How will a loss of connectivity or system availability impact your critical activities and services?
  • What is the expected or guaranteed timeline to restore service?
  • What are each parties’ responsibilities during a failure?

The last point is especially important to think about ahead of time. Many organizations wait until a disaster hits to figure out the who, what, when, where and why of recovering from it. Also, remember that vendors can sometimes make lofty promises about the availability and quality of their services when you initially explore their products and services. But unfortunately, you won’t be able to lean on those conversations in a state of emergency. Get everything in writing, and make sure your leadership team reviews all vendor contracts before they are signed.

2. What are your critical assets?

Within your system, you need to perform an impact assessment and determine which assets are critical to operation. Your assessment should include:

  • Infrastructure
  • Intellectual property
  • Financial processes, software, and tools to maintain cash flow
  • Processes to know where people are and ensure access to their location is still available

Companies often don’t realize how vast their network is and thus fail to adequately take inventory of critical assets until it is too late. One way to start this discovery is by creating an inventory of all the assets in your network. Many free and commercial tools will do this discovery and identify not just the physical devices, but the software installed on them as well. Use this inventory to start labeling the assets your business activities can’t survive without. Also, keep in mind that data is an asset as well. It might initially be easy to identify a pool of SaaS servers as mission-critical, yet there is a crucial database or file share that lives elsewhere on the network that these systems rely on.

3. How quickly do you need to recover from an adverse event?

As part of your business continuity strategy, you need to establish recovery time objectives (RTOs). These objectives define a duration of time and service level in which a business process needs to be restored. If the business continuity objectives are not met, your business can incur penalties for non-compliance with your customers’ contracts. Because RTOs are a critical part of business continuity management (BCM), they should be established in cooperation with your board or senior management. You might also want to engage the help of a third-party consultant, who may conduct a risk assessment to identify what kinds of incidents your company may face. From there, it might make sense to conduct a business impact analysis (BIA), which will help you figure out how quickly you need to recover from incidents to avoid fines and damage to your reputation. As part of the risk assessment and BIA, the consultant can help you develop RTOs and advise on other essential business continuity activities as well.

4. What do you need to do to keep the lights on?

Once you’ve decided what assets are critical to keeping the business afloat, and how quickly you need to restore them after a disruption, the next step in disaster recovery planning is to create procedures that restore impacted services during a disruption. A good practice here is to be redundant; test regularly and test often. This is an area where companies will often partner with their SaaS vendor or another third party to assist. Working together with these resources, create a technology recovery plan that contains a narrative of how you will recover from a disruptive event, the roles each person or team will own during the disruption and details of how the event will be tracked and communicated. Ensure that the communication strategy includes not just executives, but a mix of personnel mapped out in a hierarchy in case some employees aren’t able to work during the event. Make sure everyone knows how to access the communication plan. A key component to making this plan work is to perform frequent data backups that are stored offsite.

5. Put your plan in action

Your plan won’t be perfect the first time around, so it’s essential to test it out and make adjustments – ideally when you are not in a state of emergency. An effective way to proactively test your plan is with tabletop exercises. These exercises, which should be performed with a cross-functional team, give you an effective way to talk through the plan’s details and identify any gaps or areas for improvement. On the technical side, tabletop exercises are an ideal time to assemble the team and go through the motions of restoring a file, database or even an entire server. Take all the feedback you receive from the exercises – good or bad – and use it to update your disaster plan periodically to stay up to date with your business.

You do not want to be one of the many businesses that close up shop after a major incident. As part of your overall risk management strategy, take the time to review and adjust your SaaS contracts, inventory your software and hardware assets, and build out a thorough disaster recovery plan. And, as part of your business continuity planning, conduct regular testing of this plan. Doing this preparation ahead of time will save you headaches – and potentially your client base – when disaster strikes.


About the Author

, Security Engineer / Podcaster, is the president of 7 Minute Security, an information security consultancy in the Minneapolis area. Brian spends most of his days helping companies defend their networks.

Since 2004, Brian has also run the blog/podcast called 7 Minute Security, where he shares what he has learned about information security into short, 7-minute chunks.

StrongDM logo
💙 this post?
Then get all that StrongDM goodness, right in your inbox.

You May Also Like

Automating access to cloud environments
Managing Access to Ephemeral Infrastructure At Scale
Managing a static fleet of strongDM servers is dead simple. You create the server in the strongDM console, place the public key file on the box, and it’s done! This scales really well for small deployments, but as your fleet grows, the burden of manual tasks grows with it.
Illustration of an technical employee who is offboarding from their employer.
All Offboard! The 2024 Tech Staff Offboarding Checklist
Offboarding technical employees can be a complex and arduous process with a lot of moving parts. The key to successful offboarding is to have a clear understanding of what needs to be done, who does it, and how to monitor for any shenanigans from former employees.
User Provisioning: How To Automate & Manage Credentials
How We Automate User Provisioning & Keep Track of Credentials
There are a number of ways to automate user provisioning but the real challenge lies in keeping track of those credentials.
SOC 2 dashboard
What Would My SOC 2 Dashboard Look Like?
As your organization pursues your SOC 2 certification, organization is critical. ‍You will be busy actively managing dozens of ongoing daily tasks, which can bury you in minutiae. But at the same time, you need to keep your high-level compliance goals in focus in order to successfully move your certification over the finish line.
SOC 2 Policies Guide
A Definitive Guide to SOC 2 Policies
In this post, we will help you get started with a hierarchy to follow, as well as a summary of each individual SOC 2 policy.