Three Often Overlooked Elements of an Effective and Compliant Incident Response Plan (IRP)
In today’s security environment, it’s not if a cybersecurity incident will impact your institution, but when and how big? That’s why having an effective and compliant incident response plan (IRP) is so important to ensure your institution is prepared for the unexpected and equipped to recover.
When a financial institution experiences a cyber incident, the information security officer (ISO), along with the incident response team, must assess the situation and determine if this incident has resulted (or might reasonably result) in exposure of non-public personal information (NPI). If the answer is “yes,” then the team must activate the IRP to contain and control the situation and ensure quick and efficient response and recovery. When activating an IRP, there are three key elements that we sometimes see financial institutions overlook:
1. Incident Response Team Participation
When building your incident response team, it is important to include representatives from each functional unit of the institution. Too often the incident response team consists of IT personnel only. While an incident might seem to be isolated to a certain department (like IT), there could be residual effects impacting other parts of the organization.
For example, let’s say you have an incident that seems to be limited to a group of customers who received a phishing email appearing to be from the institution asking them to click a link to change their ebanking password.
In this situation, you may be inclined to simply involve IT and deposit operation teams. However, because there could be a ripple effect that goes beyond that one incident, you’ll want to include other departments such as lending, human resources, and accounting. For instance, the customer could have a lending relationship or home equity line with the institution that might be impacted as well. Or, the customer could also be a vendor. Furthermore, with the increased possibility of pretexting during a social engineering attack, the Human Resources department may want to use the incident as an opportunity to conduct refresher training to ensure employees know how to verify customer information. As such, it’s important to have all your bases covered and include all functional units on the incident response team.
2. Designated Spokesperson and Social Media Monitoring
Once you’ve activated your plan, it’s important to understand that you cannot simply hope to contain the incident within your organization. A cyber incident may involve key external stakeholders including the Board and senior management, regulatory agencies, law enforcement, third-party service providers, insurance, legal, customers, and may even attract the attention of the media.
When an incident occurs, it is important to have designated spokespeople pre-selected to communicate with each external stakeholder that needs to be informed. For example, you’d want to have your IT admin in contact with the point person at your outsourced IT company because they most likely have a direct relationship with this vendor. However, you probably wouldn’t want that same person reaching out to regulators or customers. A member of senior management would be the best choice for that. In addition, you should designate one or more individuals to be your media contact. Don’t forget to have someone monitoring social media channels to ensure news about the incident isn’t spreading online potentially exposing you to reputational harm.
When developing an incident response plan, designating spokespeople to communicate with external stakeholders and monitoring online social media channels often gets overlooked because the main focus is usually on how the incident happened and how to fix it quickly. The moment the incident response plan is activated it is critical for the incident response team to assign these roles and keep these individuals updated with any interactions they may have with stakeholders.
3. Detailed Incident Documentation and Log Retention
It is imperative that the incident response team creates detailed documentation outlining everything that occurred from the time the event was first identified, even before it became classified as an incident. Again, this is often overlooked as the team engages in containment and control activities. However, regulators, insurance companies, third-party forensics companies, the Board, law enforcement, etc., will need full details when and if they are drawn into the incident. The documentation should detail who responded, what actions were taken, when each action was taken, (the timeline), and why and how (if known) the incident occurred.
Equally important is the retention of any data logs that might assist with the response and recovery phase. Often insurance carriers will need this information if they are involved, and forensic firms will definitely need it if they are drawn into the investigation phase.
We’ll dive deeper into security event logging and best practices for responding to a cyber incident in a future blog post.