Give your team a plan it can use: seven decisions to work through with your managed I.T. partner before a cyberattack interrupts business.
Key Takeaways:
- Pair technical response steps with business authority, spending limits, and recovery priorities.
- Give your incident lead and deputy permission to act within agreed boundaries.
- Rehearse the plan with your I.T. partner, then assign and verify the fixes.
You’ve just switched your phone to airplane mode. Back at the office, your I.T. provider finds signs that a shared business application is compromised.
Suspending access could help contain the threat. It could also interrupt orders, appointments, or payroll. Your team needs a decision while you’re unreachable.
Your incident response plan for a cyberattack should make that decision possible. It connects the technical response to the people, priorities, and permissions that keep your business moving.
At Attentus, proactive partnership includes understanding your systems and the work they support. Use these seven decisions to start that conversation with your I.T. team before an urgent alert forces it.
Where would your response stall? Contact our team or call (855) 965-3231 to discuss your readiness and the support your business needs.
What Belongs in an Incident Response Plan for a Cyberattack?
An incident response plan explains how your business detects, contains, investigates, and recovers from a cyberattack. It names who leads, who can act, and how the team communicates and records decisions.
Build it with the people who’ll use it. Your I.T. partner brings knowledge of systems and dependencies; your business leaders explain which interruptions affect customers, revenue, and essential work.
A usable plan covers:
- Business priorities: Which services, people, data, and dependencies need protection first?
- Leadership and activation: Who leads, who’s the backup, and what triggers the response?
- Decision rights: Who can authorize containment, emergency spending, and outside help?
- Communications: How does the team coordinate if company accounts can’t be trusted?
- Evidence and recovery: What gets preserved, and who approves a return to work?
- Testing and upkeep: Who rehearses the plan, fixes gaps, and keeps it current?
NIST’s incident response guidance places this work within ongoing cybersecurity risk management. Your response plan should connect to your wider cybersecurity program, with responsibilities agreed before an incident.
Bring those priorities into the seven decisions below. Each one settles a different part of the response, from the first escalation to the return to work.
What’s my action item? Check whether your plan names decision-makers as clearly as technical tasks.
Decision 1: Who Activates the Plan and Takes the Lead?
Name an incident lead and deputy, then agree on activation triggers with your I.T. provider. A suspicious sign-in and a disrupted customer-facing system may need different escalation paths.
The lead keeps the response organized: who’s investigating, what’s affected, and which decisions need attention. Define when an unanswered request passes to the deputy.
Attentus’s managed I.T. services include proactive reviews of customers’ environments and technology risks. Use that ongoing relationship to clarify how a technical concern reaches the right business decision-maker.
Sameer Kadoo, a director of technology solutions at Royal Bank of Canada, designs and operates a technology business continuity program. He sees unclear approval authority repeatedly in continuity planning.
“When a key approver is not available, it usually stalls the decision to approve and proceed,” Kadoo said.
Practice the handoff before relying on it. Can your deputy find the plan, reach the response team, and exercise the authority you’ve assigned? Confirm who can bring in leadership, counsel, or other specialists.
What’s my action item? Record the activation trigger, incident lead, deputy, and escalation rule.
Decision 2: Who Can Isolate Systems or Suspend Access?
Set containment permissions with your responders before an incident. Specify what they can isolate immediately, which actions need approval, and who handles the operational consequences.
Consider a compromised laptop used to run payroll. Isolating it may be necessary, but your finance team also needs to know how that affects today’s pay run. Document that dependency while there’s time to plan.
For a shared application, agree on emergency authority and an approved work alternative where feasible. A provider that knows your systems can help explain the likely impact of each containment choice.
Responders should document what they do and preserve relevant evidence as they contain the incident. Avoid blanket instructions to shut down or wipe systems.
What’s my action item? Confirm one immediate containment permission and one boundary that requires escalation.
Decision 3: Who Can Approve Emergency Spending and Outside Help?
Ask your provider to walk through what your agreement covers and where additional authorization begins. Separate routine support from potential costs for specialist investigation, legal advice, or extra recovery work.
Review your policy with your insurer or broker: confirm reporting routes, coverage conditions, and any requirements for consent or approved response firms.
“I always recommend planning the cost to be pre-approved with a buffer instead of negotiating in case of a crisis,” Kadoo said.
Set a spending ceiling, permitted uses, and a backup approver. Include a route for costs above the limit, and keep insurance consent requirements alongside that process.
Attentus’s virtual chief information officer (vCIO) planning includes budgeting and technology-risk discussions. Bring response costs into those conversations so finance and I.T. can prepare together.
What’s my action item? Record the spending limit, backup approver, and route for engaging specialists.
Decision 4: How Will the Team Communicate if Normal Systems Are Unsafe?
If company email is compromised, “I’ll send everyone the plan” may be the wrong first move. Choose an alternative communication route that your staff and I.T. partner can both use.
CISA’s #StopRansomware Guide calls for a maintained, rehearsed communications plan. Make these three arrangements explicit:
- Choose a separate channel. Confirm it works without the potentially affected company accounts, and keep access instructions available to authorized responders.
- Verify participants. Agree how the team checks identities before sharing incident details or accepting instructions.
- Set an update rhythm. Each update should state what’s confirmed, what remains unknown, the business impact, and any decision needed.
Test the route with your provider and deputy. Include an after-hours scenario so an unanswered office phone doesn’t become the next obstacle.
What’s my action item? Have the lead and deputy reach the response team without company email.
Decision 5: Who Determines Outside Notifications and Customer Messages?
Assign a coordinator to work with counsel and relevant advisers on notifications to customers, partners, insurers, regulators, or law enforcement.
The plan should identify applicable obligations and how their deadlines are tracked. Don’t assume every incident has the same reporting clock.
Name a spokesperson, message approver, and backups. Prepare templates that explain the confirmed impact, steps customers should take, and when they’ll hear from you again.
A trusted relationship needs useful, accurate updates. Your I.T. partner should help establish the technical facts; counsel and authorized business leaders guide notification decisions and approve external messages.
If customers can’t place orders, explain the approved alternative and the next update time. Avoid promising a restoration deadline or declaring data safe before the findings support it.
What’s my action item? Name the notification coordinator, customer-message approver, and their backups.
Decision 6: Who Protects Evidence and Maintains the Decision Record?
Assign technical evidence handling to qualified responders and the business decision log to a named owner. Clarify where both records remain accessible and protected.
For each major decision, record the time, facts available, approver, action, and reason. If you pause online orders to contain a threat, capture who approved the pause and how customers will be served.
Make the record easy for the next responder to use. A clear timeline helps your provider and any specialist understand what’s already happened, reducing repeated questions during a handoff.
What’s my action item? Choose the decision-log owner and a location that works if normal systems are unavailable.
Decision 7: Who Approves Recovery and the Return to Normal Work?
Agree on recovery criteria before pressure to reopen starts building. Responders should assess containment, the integrity of restoration assets, and the checks required for the affected systems.
Then have the business process owner test a complete workflow. For an order system, that might mean confirming an order reaches inventory, billing, and fulfillment correctly.
Name who authorizes the restart after reviewing both technical findings and business checks. Give staff clear instructions about which services are available and any temporary restrictions.
Keep remaining risks visible. Record monitoring needs, unresolved limitations, and the conditions that trigger another escalation.
What’s my action item? Write the restart criteria and approval owner for one critical business process.
Put the Decisions Where Your Team Can Use Them
Create a concise decision record alongside your technical procedures. For each of the seven decisions, capture:
- Decision and affected business service.
- Primary owner and accountable executive.
- Alternate with authority to act.
- Trigger for action or escalation.
- Permitted action, spending limit, or approval boundary.
- Evidence needed to make the decision.
- Contact method and escalation route.
- Decision-log location and record owner.
Keep this record accessible to authorized responders if normal systems fail. Store passwords and recovery codes separately in your approved secure system.
Work through the record with leadership and your I.T. partner. Resolve missing permissions, outdated contacts, and unclear responsibilities together, then assign someone to maintain it.
What’s my action item? Fill in your weakest decision first. Resolve the remaining blanks with leadership and your provider.
How Often Should the Plan Be Tested?
Use an annual walkthrough as a practical baseline. Review the plan after incidents or material changes to systems, personnel, and providers, and meet any stricter requirements that apply.
The Canadian Centre for Cyber Security also recommends annual testing and revision. For a leadership walkthrough, use the opening scenario: a critical application is compromised while you’re unreachable.
Make the exercise practical: your deputy must find the instructions, your provider explains the containment step, and finance follows the spending-approval route. Note where people hesitate or make conflicting assumptions.
Assign an owner and deadline to each gap, then retest the failed handoff. Carry any larger system or budget changes into your regular I.T. planning discussions.
What’s my action item? Schedule a walkthrough that deliberately removes the main approver.
Frequently Asked Questions About Incident Response Planning
1. How is an incident response plan different from a disaster recovery plan?
An incident response plan coordinates investigation, containment, communication, and recovery. A disaster recovery plan focuses on restoring systems and data. Connect them so restoration follows technical findings and business priorities.
2. What if we don’t have an internal I.T. team?
Work with your managed I.T. provider to define technical duties and escalation routes. Assign an internal business lead and deputy who can make operational decisions, approve spending, and coordinate customer communications.
3. What should we bring to our first planning discussion?
Start with your critical business services, key contacts, provider agreement, existing recovery procedures, and any cyber-insurance response requirements. Ask your provider to help identify system dependencies and gaps in that information.
4. Can an I.T. provider own the entire incident response plan?
Your provider can lead agreed technical work and help maintain the plan. Leadership still owns business priorities and must delegate spending, communication, and restart decisions explicitly. Confirm each party’s responsibilities in writing.
Build Readiness Into the Relationship
The most useful response planning happens while business is running normally: when your provider learns how work flows, your leaders discuss priorities, and your team rehearses the difficult calls.
That’s how Attentus’s “Be the Answer” and “Build Trusted Relationships” values apply here: make the next step clear, explain the business impact, and follow through on improvements together.
Start With One Business-Critical Process
Choose the application your team can least afford to lose. Talk with Attentus about how your cybersecurity and managed I.T. support connect to the seven decisions above, and discuss a walkthrough of the gaps.