Creating an Incident Response Plan

Advisors often ask me what more they can be doing security-wise—not just to keep compliant with regulations but also to make sure they aren’t putting both their offices’ and clients’ information at risk. After all, most of our advisors have great technical controls due to the Commonwealth Shield, and many blend in some security awareness training for a more comprehensive approach. The gaps appear to be covered.

But even if you have all of the right elements in place, you still aren’t answering one crucial question: What if your controls fail? The earlier you plan for such mishaps, the less impactful they will be when they happen to you. So if you don’t have one already, the time to start creating an incident response plan (IRP) is now.

An IRP can help protect your firm's information in the event of a security incident, defined as any event that negatively affects a critical information asset’s: 

• Confidentiality (e.g., disclosure to unauthorized users)
• Integrity (e.g., unauthorized modification)
• Availability (e.g., destruction, outage)

For your IRP, it’s best to create three to five specific scenarios that are most likely to affect your firm and use those as your model when thinking of an “incident.” Common scenarios include: 

• Malicious software (malware) infection
• Unauthorized disclosure of sensitive information, such as personally identifiable information or protected health information
• Denial-of-service attack
• Physical theft (of hard drives, laptops, paper documents, etc.)
• Fraudulent wire transfer

Once you've thought about the scenarios, you're ready to take the next steps for developing an IRP: 

1) Determine the purpose and scope. An IRP should begin with a brief purpose statement (1–2 sentences) that explains what it should do and why your firm needs it. Everything in your IRP should exist for this purpose—but keep in mind that you can’t predict every scenario, so you need to build in a level of flexibility.

The scope immediately follows the purpose statement and defines exactly what the IRP covers. Here, include three to five common security incidents. Be sure to explain where you draw the line between an incident and a disaster (e.g., floods, hurricanes, prolonged power outages, riots), which should be addressed by a separate disaster recovery plan. 

2) Define roles and responsibilities. When an incident occurs, you don’t want everyone on your staff waiting around for someone else to do something, so this step is critical. Each person should have a clearly defined role as part of your incident response team (IRT).

In a relatively small organization, it's likely that you, your staff members, and your broker/dealer will wear multiple hats. Essential roles include: 

• Incident lead. The incident lead is the person who declares an incident and holds the ultimate responsibility when an incident occurs.
• Legal counsel. You’ll need to know whether an incident falls under your state’s breach notification laws. Here at Commonwealth, for example, we'll act as legal counsel for our advisors and review statutes to determine whether client communications are necessary.
• Communications specialist. If an incident does require breach notification, you’ll need a skilled communicator—typically one of your staff members—to reach out to your clients.
• External technical team. Incidents often require technical expertise that your firm may not possess. Be sure to research external tech companies to create a list of potential resources. For securely wiping a hard drive, you could use a big chain like Best Buy; for digital forensic analysis, however, you’ll need a more specialized team on hand.

3) Categorize incident severity ratings. The severity of incidents can be wide-ranging. You wouldn’t want to treat a personally identifiable information breach the same way that you’d treat an office-wide incident of ransomware.

Best practice is to list three severity ratings (1–3 or A–C), and define the criteria for each. Here, financial impact and potential damage should be top of mind. The chart below provides a sample severity rating table.

4) Create a response workflow. A response workflow will outline next steps for dealing with an incident, plus keep you and your staff from panicking and perhaps making a bad decision in the heat of the moment. This high-level list of steps (no more than eight) should be general enough to apply to all of the scenarios you defined in the scope section of your IRP. 

Here’s an example of an incident response workflow: 

1. Preparation: Create an IRP to meet your firm’s specific needs in the event of an incident.
2. Detection: Confirm that an event is actually a security incident.
3. Reporting: Inform management, responders, and your broker/dealer.
4. Mitigation: Contain the incident to limit its impact (e.g., disconnecting an infected computer from the network).
5. Recovery: Bring the affected system back to an operational state.
6. Remediation: Identify the root cause of the incident, and take the proper steps to prevent it from occurring again.
7. Lessons learned: Evaluate the incident response workflow and how it could be improved.

5) Review your IRP. Your IRP should be reviewed at least annually, as well as when any significant changes occur that may affect your incident response workflow (e.g., office relocation, office-wide hardware upgrade). In addition, periodically testing your IRP is critical. You don’t want to discover issues with your plan when it’s time to use it! We recommend conducting an annual tabletop exercise with your internal IRT.

This exercise is an opportunity to walk through a crisis event in a non-crisis environment. Choose one of your three to five scenarios and talk through how your firm would handle it, step by step. Update your IRP as you discover new things.

Once your IRP is complete, it should be classified as highly confidential and stored in a secure place. Only those employees who are actively involved in your IRT should be allowed access. For example, the staff member who will write your communications should have access, but your new intern who has no intentions of being involved shouldn’t have permission to read the document.

Also, you should not share the document with your clients. An IRP holds valuable information about how your firm handles security; in the event that it falls into the wrong hands, an attacker would have valuable information on how you would respond to a hit.

If your client does ask what would happen if your office were to suffer a data breach? An appropriate response would be, “We have a response plan in place in the event of a cyber-related incident. We rely on our broker/dealer, as well as other third parties, for additional help. And we review and test our plan at least annually.”

Security isn’t just about the controls that protect your information; it’s also about having a plan in case all goes wrong. An IRP is a big piece of the puzzle that many forget to consider, but keeping a well-documented plan can save you a lot of potential damage when an incident does occur.

Do you have an IRP in place? How often do you test it? Please share your thoughts with us below!