Business Continuity and Your Incident Response Plan

Have you ever been concerned about the existential risk your business faces? Do you worry about what your customers would do if you weren't available to respond to their needs?

Your fears aren't unfounded.

According to The Global State of Information Security Survey 2015, a worldwide study by PwC, CIO, and CSO security incidents caused downtime of more than 8 hours for 31% of impacted organizations. And the Insurance Journal reports that the average cost of a corporate data breach increased 15 percent from 2013 to 2014, to $3.5 million.

When fears and reality align, it's a good indication that it might be time for an incident response plan.

The benefits of instituting an incident response plan are both measurable, like improved recovery time, and intangible, like the peace of mind that having a defined plan can afford you. Whatever benefits you personally experience, there's no question that crisis response planning has very real value.

Why You Should Develop an Incident Response Plan

The most obvious benefit of establishing an incident response plan is that the sooner you are able to address an event, the better.

Having a documented plan will also mean you'll be more prepared to identify possible concerns, and that, necessarily means you'll be able to respond to those concerns either proactively or at least more quickly should a breach actually occur.

As a result, not only will your customers experience less interruption to service, but you'll realize minimized losses, and can effectively protect the reputation of your business. Explains Alex Insley, Twinstate's Unified Defense Strategies technical manager, "Depending on your response and what you have to say to clients and customers, and on how you distribute the right amount of info to the right people and how quickly, the perception of the incident will differ. If you respond poorly, but get all your data back, you've still risked your reputation."

Having a plan in place allows you to dictate exactly what to say to who, and when, to ensure your response reflects your business values and doesn't raise concerns in addition to the actual breach.

How to Get Started

To create a plan you can implement in your business, begin with identifying what, exactly, would qualify as an incident. Would your plan cover a suspicion that an employee had stolen data? Would it cover a malware infection on one machine? Or only address malware as an incident if the infection spread to more than one machine? Setting parameters to determine what "counts" as an incident and what does not is your first step to creating a comprehensive plan.

Next, you need to identify how you'll discover these incidents. Put a system in place that tells your employees where to look for certain types of behavior.

"Ask: What can I put in place to ensure this is brought to my attention in a timely fashion?" says Insley. "Is it a person? Is it a piece of software?" It's important to include the identification and report of an incident as part of your response plan.

Once you've chosen your qualifiers and identified how you'll learn about an incident's occurrence, you'll need to begin to form the process of response. Imagine you receive a piece of paper that tells you there has been an incident. What do you do next? Who should be responding and reporting on the response? What are their tasks within that process?

"You don't want just anybody responding," says Insley. "A response can be expensive. You're asking people to work nonstop until something is fixed. So you need to ensure the right people have access to the plan."

The document you create (your plan) should include the following details:

• Exactly what qualifies an event as an incident and why
• How to identify a potential incident before it occurs
• Who is responsible for the response
• What materials and information that person needs to gather
• Who to call based on the incident level, with relevant contact information (Note: Sometimes this might be law enforcement; your plan should detail when reporting the incident is necessary and when it is not.)
• What information to share with which customers and stakeholders
• What information not to share with your customers
• The format and language for relaying that information
• Your Recovery Time Objective (RTO)
• What alternative systems to use to serve customers until recovery is complete

Other big items will also need to be on your list, many specific to your organizational structure and needs. How you choose to build your response plan is up to you, but having one is absolutely necessary. Not only will it help you react more quickly and maintain credibility, business continuity and productivity, but it can also help you minimize lost productivity, potentially avoid regulatory fines, and get to sleep at night. And that's real security.