JR Aquino

Incident response is a discipline around managing a crisis. The core of this activity is to provide a central control point for information and alignment on execution using the best information available at the time. We should first start by disambiguating an internal incident versus a customer or third-party impacting incident, which requires notifications to those affected.

When harm has befallen your company’s data, infrastructure, or service(s) and there is no impact to third parties, upon remediation, the event could be considered contained and may only require internal recordkeeping for compliance purposes.

When harm has befallen your customer’s service, data, or personally identifiable data your company manages, you may have an obligation to report the incident to the impacted third parties and/or regulators. These are the cases that are most sensitive and require coordination to ensure that contractual, regulatory, and business obligations are all fulfilled.

It’s useful to note here that most incidents you encounter will have no “hacker” involved. Most of the incidents that you are likely to manage will be due to human error.

Let’s dive right in and establish the core fundamentals that you will need to prepare for a security incident that requires notifications.

Assume breach

The first order of business is to “assume breach.” What I mean here is to have a plan of action with necessary steps so that in the event of a crisis, you already have the documentation and training prepared ahead of time.

• Have an incident response plan documented

• Create a status update template

• Keep a contact list with a roles and responsibilities matrix up to date

Keep the business up to date

There are going to be a lot of different activities going on during a crisis. Keeping track of all these workstreams and articulating them to leadership is paramount.

• Make sure compliance staff is aware and tracking audit evidence

• Ensure your legal representation is engaged

• Establish expectations of a rhythm of status updates (e.g., hourly, daily, weekly, etc.)

Identify the impacted parties

• Enumerate how many entities are affected

• Differentiate between first and third parties

• Attribute contact info to the impacted data assets

Prepare your staff for external parties reaching out about the incident

Once communications have gone out, there will be an influx of inbound support requests from those who were notified.

• Establish talking points for customer-facing staff like support and sales

• If you have a PR or comms team, make sure they’re engaged

• Monitor social media and news outlets

Keep a detailed timeline of events

• When does the evidence indicate the event occurred?

• When did the company become aware of the event?

• When were steps were taken to contain, mitigate, and remediate the incident?

Publishing customer communications

• Work with the stakeholders to ensure you have an accurate depiction of the impact, the affected parties, and the steps that have been taken and/or planned

• Stakeholders that should be contributing to the comms: engineering/legal/comms/security/compliance/business leadership

Post-incident review (PIR): Improvement goals

It may not feel like it at the time, but every incident is a gift. Each incident you face gives you an opportunity to improve your processes. Perform a post-incident review to continuously improve your program.

• Identify steps that could eliminate or reduce the risk of the incident reoccurring

• Identify improvements needed to diagnose the incident including service impacted, priority level, and the correct resolver teams to be engaged

• Ensure incident communication was proper or if anything can be improved

• Update the incident response standard operating procedures (SOP)