← Back to all posts

The Incident Response Plan You Don't Have (But Need)

March 8, 2026

The Incident Response Plan You Don't Have (But Need)

The Incident Response Plan You Don't Have (But Need)

At 2:47am last Tuesday, a client called me. Ransomware. Every server encrypted. Backups compromised. Business at a standstill.

"What's our incident response plan?" they asked.

Silence.

They didn't have one. Like most SMBs, they'd never gotten around to it. "We'll do it next quarter," they'd said. For three years.

Here's the thing about incidents: they don't wait for you to be ready. They don't care about your busy schedule. They just happen.

If you don't have an incident response plan template tailored to your business, this article is for you. And you need to read it today, not "next quarter."


Why SMBs Skip Incident Response Planning

I get it. Incident response feels like enterprise stuff. Something for banks and telcos with dedicated SOC teams.

You're a 50-person professional services firm. Or a regional manufacturer. Or a healthcare clinic. You're not handling classified data. Surely you don't need a formal IR plan?

Wrong. Here's why:

Incidents Are Inevitable

If you have computers, you will have incidents. Maybe not ransomware. Maybe:

  • A phishing email that works
  • Lost laptop with client data
  • Accidental data deletion
  • Insider threat
  • Vendor compromise

The question isn't if. It's when. And when it happens, having a plan vs. making it up as you go is the difference between a bad day and a business-ending disaster.

Chaos Is Expensive

Without a plan, every decision becomes a debate:

  • Who's in charge?
  • Do we pay the ransom?
  • Do we call the police?
  • Do we tell clients?
  • Who talks to the media?
  • Do we shut down systems?

These debates happen while the clock is ticking. While data is being exfiltrated. While evidence is being destroyed.

A plan gives you pre-made decisions. Clear roles. Documented procedures. You execute instead of arguing.

Regulators and Clients Expect It

Under the Australian Notifiable Data Breaches scheme, you have obligations when personal information is compromised. Having an incident response plan demonstrates due diligence.

More importantly, clients increasingly expect it. Cyber insurance questionnaires ask about IR plans. Enterprise clients ask about them in RFPs. A documented plan becomes a competitive advantage.


The SMB Incident Response Plan Template

You don't need a 200-page document. You need something practical. Here's my incident response plan template for SMBs:


[COMPANY NAME] Incident Response Plan

1. Purpose and Scope

This plan provides procedures for responding to cybersecurity incidents affecting [Company Name]'s information systems, data, and operations.

Scope: This plan covers all information systems, networks, and data owned or managed by [Company Name].

Last Updated: [Date]

2. Incident Classification

SeverityDefinitionExamplesResponse Time
CriticalBusiness operations severely impacted or significant data breachRansomware, major data breach, system-wide outageImmediate
HighSignificant impact to specific systems or potential data breachSuccessful phishing with account compromise, malware outbreakWithin 4 hours
MediumLimited impact, contained threatBlocked phishing attempt, isolated malware, suspicious activityWithin 24 hours
LowMinimal impact, no data lossSpam, port scans, failed login attemptsWithin 72 hours

3. Incident Response Team

Core Team

RoleNameContactResponsibilities
Incident Commander[Name][Phone/Email]Overall coordination, decision authority, external communications
Technical Lead[Name][Phone/Email]Technical investigation, containment, recovery
Communications Lead[Name][Phone/Email]Internal communications, client notifications, media
Legal/Compliance[Name/External][Phone/Email]Regulatory requirements, legal advice, contracts

Extended Team (As Needed)

  • IT support staff
  • Department heads
  • HR (for insider threats)
  • External incident response firm: [Contact]
  • Cyber insurance: [Policy number and contact]

4. Incident Response Phases

Phase 1: Detection and Reporting

How to Report:

  • Email: security@[company].com
  • Phone: [Number]
  • Slack: #security-incidents
  • In person: Notify your manager or IT immediately

What to Report:

  • Suspicious emails or messages
  • Unusual system behaviour
  • Lost or stolen devices
  • Suspected account compromise
  • Any security concern, even if unsure

Detection Methods:

  • Automated alerts (EDR, SIEM, email security)
  • Employee reports
  • Customer notifications
  • Third-party notifications

Phase 2: Assessment and Classification

Initial Assessment (First 30 minutes):

  1. Verify the incident is real (not false positive)
  2. Determine scope: what systems/data are affected?
  3. Classify severity using table above
  4. Notify Incident Commander
  5. Activate appropriate team members

Documentation:

  • Start incident log immediately
  • Record all actions, times, and decisions
  • Preserve evidence (screenshots, logs)
  • Chain of custody for forensic evidence

Phase 3: Containment

Short-term Containment (Immediate):

  • Isolate affected systems (disconnect from network)
  • Disable compromised accounts
  • Block malicious IP addresses/domains
  • Preserve evidence before remediation

Long-term Containment (Hours to days):

  • Deploy patches or configuration changes
  • Enhance monitoring
  • Implement temporary workarounds
  • Secure backup systems

Phase 4: Eradication

  • Remove malware and artifacts
  • Close attack vectors
  • Patch vulnerabilities
  • Reset compromised credentials
  • Verify threat is eliminated

Phase 5: Recovery

  • Restore systems from clean backups
  • Verify integrity of restored systems
  • Return to normal operations gradually
  • Enhanced monitoring during recovery
  • Validate security controls are functioning

Phase 6: Post-Incident

Immediate (Within 1 week):

  • Incident summary report
  • Notification to affected parties (if required)
  • Insurance claim submission
  • Preserve evidence for potential legal action

Follow-up (Within 1 month):

  • Full incident analysis (root cause)
  • Lessons learned meeting
  • Update security controls
  • Revise incident response plan
  • Staff communication (as appropriate)

5. Communication Templates

Internal Notification (Initial)

Subject: Security Incident - Response Underway

We have identified a security incident affecting [systems]. An incident response team has been activated and is working to contain and resolve the situation.

Do not:

  • Discuss this incident on social media
  • Contact media
  • Attempt to access affected systems

Do:

  • Report any suspicious activity to [contact]
  • Continue normal operations on unaffected systems
  • Direct external inquiries to [spokesperson]

We will provide updates every [timeframe].

Client Notification (If Required)

Subject: Important Security Notice

We are writing to inform you of a security incident that may have affected your personal information.

What happened: [Brief, factual description] What information was involved: [Specific data types] What we are doing: [Response actions] What you should do: [Protective steps for clients]

We sincerely apologise for this incident. Protecting your data is our priority.

For questions, contact: [dedicated line/email]

6. Key Contacts

ServiceProviderContactNotes
Cyber Insurance[Insurer][Phone/Policy]24/7 hotline
External IR Firm[Firm][Phone/Email]Retainer: [Y/N]
Legal Counsel[Firm][Phone/Email]
IT Support[Provider][Phone/Email]
Forensics[Firm][Phone/Email]
Police131 444 (Cybercrime)
ACSChttps://www.cyber.gov.auReport cyber incidents
OAIC1300 363 992Privacy breaches

7. Legal and Regulatory Obligations

Notifiable Data Breaches (NDB) Scheme

If personal information is subject to unauthorised access or disclosure, we may be required to notify:

  • Affected individuals
  • Office of the Australian Information Commissioner (OAIC)

Timeline: Assess within 30 days; notify if serious harm is likely.

Process: Legal/Compliance lead assesses and manages notifications.

Other Obligations

  • Industry-specific regulators (if applicable)
  • Contractual notification requirements
  • Cyber insurance notification requirements

8. Recovery Priorities

Tier 1 (Critical - Restore First):

  • [System 1 - e.g., Email]
  • [System 2 - e.g., Customer database]
  • [System 3]

Tier 2 (Important - Restore Second):

  • [System 4]
  • [System 5]

Tier 3 (Defer):

  • [System 6]
  • Non-critical systems

9. Plan Maintenance

This plan will be reviewed and updated:

  • Annually (minimum)
  • After each incident
  • When significant systems or staff change
  • When regulations change

Next Review Date: [Date]


Securing your workplace? You're probably your family's IT person too.

The same principles that protect enterprise data—having a plan, knowing who to call, being prepared—work just as well at home. But most families have none of it.

Get my Personal Security Quick-Start Guide — the 193-page practical handbook for busy people who want to protect their families without becoming cybersecurity experts.

Plus: Join 158+ Australians getting one 5-minute security briefing every Friday.

Get The Free Guide →


Customising This Template

The template above is a starting point. Here's how to customise it for your business:

1. Fill in the Blanks

Add your:

  • Company name
  • Actual contact details
  • Specific systems and priorities
  • Real provider contacts

2. Adapt the Severity Levels

What's "critical" for you? Maybe:

  • POS system down (retail)
  • Patient records inaccessible (healthcare)
  • Design files encrypted (creative agency)

Define severity based on business impact, not technical complexity.

3. Identify Your Actual Response Team

In a 20-person business, your "incident response team" might be:

  • You (business owner)
  • Your IT provider
  • Your lawyer
  • Your insurance broker

That's fine. Write down their actual names and numbers.

4. Test the Plan

Do a tabletop exercise:

  • "Ransomware hits on Friday at 6pm. Walk through the response."
  • "An employee falls for a wire transfer scam. What do we do?"
  • "A laptop with client data is stolen. Who do we call?"

You'll find gaps. Fix them before a real incident.


The "We Can't Afford IR Retainers" Problem

Proper incident response firms charge retainers. $10,000+ per year. Many SMBs can't justify that.

Here's the compromise:

Minimum viable preparation:

  1. Identify 2-3 incident response firms that serve SMBs
  2. Get their emergency contact details
  3. Understand their pricing (hourly rates, minimums)
  4. Have their contact info in your plan

You don't need a retainer. You just need to know who to call at 2am.

Many firms will do initial assessments and triage without a retainer. You'll pay more per hour, but you're not locked into an annual fee.


When to Call for Help

Not every incident needs external help. Here's my guidance:

Handle internally:

  • Blocked phishing attempts
  • Individual malware infections (standard cleanup)
  • Failed login attempts
  • Minor policy violations

Call your IT provider:

  • Successful account compromise
  • Multiple infected systems
  • Network anomalies
  • Ransomware (immediate)

Call external IR firm:

  • Confirmed data breach
  • Ransomware with exfiltration
  • Insider threat
  • Legal/regulatory exposure
  • Media attention likely

Call police:

  • Financial fraud (wire transfers, etc.)
  • Threats or extortion
  • Significant criminal activity

Don't Forget the Basics

An incident response plan is important. But it's not a substitute for prevention:

  • Backups: Tested, immutable, offline
  • MFA: On everything
  • Patching: Current and automated
  • EDR: On all endpoints
  • Email security: Filtering and protection
  • Training: Staff know how to spot and report

The best incident response is preventing the incident. But when prevention fails—and it will—you need a plan.

And if you want to learn more about building comprehensive security programs, check out our guide to ransomware protection — because that's the incident most SMBs fear.


Mathew Clark
Founder, SecureInSeconds
Currently: Updating our own incident response plan after realising half the phone numbers were out of date


Further Reading: