An incident response plan gives a business a calmer way to handle a suspected cybersecurity event. It is not a dense policy written for a compliance binder. It is a short, usable plan that tells people who makes decisions, who calls for help, what must be protected first, and how the organization will keep working while it gets reliable answers.
That preparation matters because the first few hours of an incident are often confusing. A staff member may report an unusual sign-in prompt, a vendor may flag suspicious activity, a laptop may behave strangely, or critical files may suddenly be unavailable. Without a plan, people can take well-intentioned actions that make the situation harder to investigate or contain. With a plan, leadership can protect the business while qualified technical support determines what happened.
1. Start with the business consequences
Begin by naming the work that would be most affected by a cybersecurity incident. That might include client communication, access to financial systems, scheduling, payroll, shared files, dispatch, patient records, case management, or the applications your team uses to serve customers. This keeps the plan focused on what the business needs to protect, rather than on a generic list of technical tools.
For each critical activity, identify the systems, information, people, and vendors that support it. Then ask what would happen if access were interrupted for an hour, a day, or several days. A clear answer helps leadership set priorities before stress and incomplete information take over. ShorePointIT's overview of common technology pressures can help teams identify the everyday dependencies worth including.
Also decide what would count as a reportable concern. Examples may include a suspected account takeover, a lost device with business access, an unexpected payment request, a ransomware message, a cloud service alert, or a third party saying it received a suspicious message from your organization. The plan does not need to diagnose every event. It needs to give people a reliable trigger for escalating one.
2. Name the people who own the first decisions
A response slows down when everyone assumes someone else is in charge. Create a small incident response team with clear roles. One leader should be able to authorize business decisions. One person should coordinate the technical response. One person should own internal and customer communication. The plan should also name backup contacts, because the first call may happen when a key person is unavailable.
Include the contact details for your managed IT provider, cyber insurance carrier, legal counsel, bank or payment provider, internet provider, and any essential software vendors. Keep that list in a secure location that can be reached if normal email or shared files are unavailable. It is also worth recording who controls each vendor account and where the administrative access is held.
Use plain job descriptions in the template. The business lead decides what work must continue and what communication is appropriate. The technical lead investigates, contains, and documents the issue. The communications lead keeps employees and affected customers informed with approved information. Those roles can be held by the same person in a small business, but the responsibilities should still be explicit.
3. Use this incident response plan template
A useful plan can fit on a few pages. Copy the following sections into a working document, fill in the names and contact details, and review it with the people who would need to use it. Keep the language specific to the business, not to a generic security program.
- Incident trigger: What events should be reported immediately, and how should an employee report them?
- Business priorities: Which client services, systems, records, and communication channels must be protected or restored first?
- Response team: Who is the business lead, technical lead, communications owner, and backup for each role?
- Critical contacts: Which technology providers, insurers, counsel, banks, and vendors may need to be called?
- First-hour actions: Who logs the concern, preserves evidence, authorizes urgent support, and decides whether to pause a risky activity?
- Containment options: When can access be disabled, a device isolated, a payment delayed, or a vendor account temporarily restricted?
- Communication: Who receives internal updates, what customers need to know, and who approves any external statement?
- Recovery and review: How will the business restore access, confirm the issue is resolved, and capture improvements after the event?
This structure follows the practical lifecycle described in the NIST incident response guidance: prepare, respond, recover, and use the lessons to improve the organization. The point is not to copy a government framework word for word. It is to make sure the business has a workable sequence before it needs one.
4. Protect evidence before making broad changes
When an incident is suspected, the instinct is often to fix the most visible problem immediately. That can be the right move in a clear emergency, but broad changes made too early can also erase useful evidence or disrupt more people than necessary. Ask the technical lead or qualified IT partner to record what was reported, when it was noticed, which accounts or devices are involved, and what actions have already been taken.
Do not tell employees to forward suspicious messages broadly, delete the original evidence, or restart every affected device without direction. Preserve the email, screenshot, alert, or device details. Then allow the response team to decide how urgent the risk is and which containment step is appropriate. For ransomware-specific situations, the CISA ransomware guide also emphasizes acting from a documented plan and engaging the right support.
Make sure the plan includes a simple incident log. It can be a secure document, a ticket, or a paper form kept with the response materials. Record the time, reporter, systems involved, decisions made, contacts called, and next update time. That log gives leadership a shared view of the response and makes the later review much more useful.
5. Contain the problem with a clear business decision
Containment means limiting further exposure while the team investigates. Depending on the incident, it may mean disabling an account, removing a device from the network, pausing a payment request, resetting access for a small group, or asking a vendor to temporarily restrict a system. The right choice depends on the facts, which is why the plan should identify who can authorize it.
Every containment action has a tradeoff. Disconnecting a system may protect information but interrupt operations. Leaving it connected may preserve access but increase risk. The response team should decide with both the business and technical consequences in view. That is much easier when leaders have already identified what work can tolerate a short pause and what requires an immediate alternative.
Identity protection is especially important here. Many incidents begin with a compromised account, an unexpected authentication request, or access that was never removed. ShorePointIT's cybersecurity services help organizations strengthen identity controls, endpoint protection, cloud security, and ongoing awareness so the response does not rely on luck or memory.
6. Communicate enough, not too much
During a security event, employees and customers need useful direction, not speculation. The plan should name who can approve updates and where those updates will be delivered if normal systems are unavailable. A first message can be short: acknowledge the issue, explain the action people should take now, and say when they can expect another update.
Employees may need a specific instruction, such as not approving payments, not responding to a suspicious thread, using a temporary communication channel, or bringing a device to IT. Customers may only need to know that the business is investigating a service interruption and will provide an update. Avoid guessing about cause, scope, or timing before the facts are known.
Prepare a few short templates in advance for employees, leadership, customers, and vendors. This removes the pressure to write from scratch during an incident and reduces the chance that someone shares incomplete information. The business lead should still review the actual message, because the right communication depends on the incident and the people affected.
Keep a record of what was communicated and when. In a fast-moving event, a simple timeline prevents mixed messages and helps the response team see which questions still need an answer. It also gives leadership a reliable account of the decisions made, without asking employees to rely on memory after a stressful day.
7. Recover in the order the business needs
Recovery is more than turning systems back on. The response team needs to confirm that access is safe, critical work can resume, and the business has not restored the same weakness that caused the incident. Start with the priorities defined in the plan: client-facing work, essential communication, financial processes, or records that support daily service.
Backup and recovery decisions should be made before an incident, not while one is unfolding. The business should know what data is backed up, who can authorize a restore, how long recovery is likely to take, and what temporary process can support essential work. ShorePointIT's managed service levels include monitoring, backup coverage, recovery planning, and continuity readiness for organizations that need more dependable support around those decisions.
A business continuity plan complements this response plan. The incident response plan focuses on managing the cybersecurity event. The continuity plan focuses on keeping essential work moving through any disruption. Use the business continuity plan checklist alongside this template to make sure both parts are covered.
8. Practice the first hour, then improve the plan
The most useful test is a short tabletop exercise. Choose a realistic scenario, gather the people named in the plan, and talk through the first hour. For example, a finance employee receives a suspicious payment request, a manager cannot access a key cloud account, or an endpoint alert suggests malicious activity. Ask who gets called, what evidence is saved, what work must continue, and what message employees need.
The exercise should reveal gaps. Maybe the insurance contact is outdated, nobody knows who owns a vendor portal, or the leadership team has different views about whether to pause a payment process. Those findings are valuable. Turn them into a short, owned improvement list instead of treating the exercise as a pass-or-fail event.
Review the plan at least once a year and after changes in leadership, key systems, vendors, locations, or client obligations. It should also be reviewed after any real incident. ShorePointIT's IT risk assessment checklist is a useful companion for identifying the technology, access, vendor, and recovery gaps that can make an incident harder to manage.
How ShorePointIT can help
ShorePointIT helps growing organizations make cybersecurity and continuity planning practical. A free technology and cyber risk assessment can identify gaps around accounts, devices, backup, vendor ownership, recovery readiness, and response roles. The result is a clearer plan for protecting the work your business cannot afford to interrupt.
