A customer calls about a strange message from your company. Your employee cannot explain it, the mailbox is acting differently, and nobody is sure who should make the next call. An incident response plan is useful because it settles some of those questions before you are answering them under pressure.
The plan does not need to predict every attack. It needs to identify the people who can assess a report, authorize action, communicate clearly, and help the business keep operating. Start with a short usable document, then test it. A long document nobody can find will not make the first hour easier.
Give the first report somewhere to go
Tell employees how to reach help and what to report, including an unexpected sign-in, a suspicious payment request, or a lost device. They should not have to prove an attack happened before they can ask. Keep an alternative contact route available in case company email or the normal collaboration app is part of the problem.
Assign a business decision-maker and a technical response contact. Record who can approve disabling an account, isolating a device, or interrupting an application. Include backup contacts. Those choices can affect operations, so the plan should reflect the authority people actually have.
Contain the issue without losing useful evidence
The appropriate action depends on what happened. A compromised identity, a malicious file, and a payment diversion may need different responses. Have qualified responders guide containment and evidence handling. Avoid casual cleanup that destroys logs or makes it harder to understand the scope. Keep a record of decisions and the time they were made.
NIST’s current incident response guidance, SP 800-61 Revision 3, treats response as part of ongoing cybersecurity risk management. Preparation, detection, response, and recovery support one another. Writing the plan is one part of that work; keeping contacts, permissions, and technical visibility usable is another.
Source: NIST SP 800-61 Revision 3, incident response
Plan the conversations as well as the technical work
- Keep bank, insurer, legal, IT, and leadership contact details available outside the affected system.
- Decide who approves messages to employees, customers, and business partners.
- Identify contractual and legal notification questions for qualified advisers to assess.
- Agree on how status updates will be shared if the normal communications channel is unavailable.
RIKR has helped people recover compromised mailboxes and social accounts and work through the resulting mess, including recommendations about communications to downstream customers. That experience is a reason to prepare the conversation before it becomes urgent. We do not assume every incident needs the same customer message or that the first explanation is the complete one.
Practice one realistic scenario
Choose a situation such as a mailbox takeover. Ask who receives the report, who contacts the bank if a payment is involved, and how customers can verify a legitimate message. Record the gaps and give each one an action. The exercise has value when someone follows up on what it reveals.
RIKR will take charge of coordinating an incident within the agreed engagement. Projects and extensive security-incident remediation are quoted separately. Scope should be clear ahead of time, including how specialist support, insurance requirements, and business decisions fit together.
Related: running a cybersecurity tabletop exercise
Explore RIKR managed cybersecurity
Written by Joshua Price
Back to the blog