MSP Data Breach Response Plan: What to Do When Things Go Wrong
Your MSP calls on a Saturday morning. There has been a security incident. Client data may have been accessed. You need to act now.
The difference between a manageable incident and a catastrophic one often comes down to what happens in the first 48 hours. Having a plan before you need it is the only way to ensure your response is effective, coordinated, and compliant.
A data breach response plan is not a document you create after a breach. It is a living capability you build, test, and maintain so that when the inevitable happens, you are ready.
Understanding Data Breach Obligations in Australia
The Notifiable Data Breaches (NDB) Scheme
The NDB scheme under the Privacy Act requires organisations to:
- Assess whether a breach is an eligible data breach (likely to result in serious harm)
- Notify the OAIC as soon as practicable after forming the belief
- Notify affected individuals as soon as practicable
- Record the breach and response actions regardless of whether notification is required
What Constitutes "Serious Harm"
The OAIC considers: - Type of harm — physical, psychological, emotional, financial, or reputational - Sensitivity of information — health, financial, or identity information is higher risk - Volume of information — more data exposed means greater risk - Nature of the breach — targeted attack vs. accidental disclosure - Security protections — encryption, access controls, and other safeguards in place
Notification Requirements
| Breach Type | OAIC Notification | Individual Notification | Timeline |
|---|---|---|---|
| Eligible breach | Required | Required | As soon as practicable (max 30 days) |
| Non-eligible breach | Not required | Not required | Record internally |
| Unknown severity | Assess first | Depends on assessment | Within 30 days of awareness |
The Incident Response Framework
Phase 1: Detection and Identification (0-4 hours)
Immediate actions: 1. Confirm the breach. Is this a real incident or a false alarm? 2. Identify scope. What data was affected? How many records? Which systems? 3. Activate the team. Notify key personnel per your incident response plan 4. Preserve evidence. Do not delete logs, do not turn off systems 5. Begin containment. Isolate affected systems to prevent spread
Who does what: - MSP: Technical investigation, system isolation, evidence preservation - Internal IT/Security: Coordination, business impact assessment - Management: Business decisions, stakeholder communication - Legal: Notification obligations, liability assessment
Phase 2: Containment (4-48 hours)
Short-term containment: - Disable compromised accounts - Isolate affected systems from the network - Block malicious IP addresses or domains - Change credentials for affected services - Implement additional monitoring
Long-term containment: - Deploy additional security controls - Segment the network to limit lateral movement - Update firewall rules and access controls - Begin system hardening
Preserve evidence: - Image affected systems before remediation - Collect and preserve logs - Document all actions taken - Maintain chain of custody for evidence
Phase 3: Investigation (24 hours - 4 weeks)
Determine: - How the breach occurred (attack vector) - What data was accessed or exfiltrated - When the breach occurred (timeline) - Who is affected (individuals, organisations) - Why the breach succeeded (root cause)
Forensic analysis: - Review system and network logs - Analyse malware samples - Examine access patterns - Interview relevant personnel - Document findings comprehensively
Phase 4: Notification (Within 30 days)
OAIC notification must include: - Description of the breach - Types of information involved - Steps taken to contain and remediate - Recommendations for affected individuals - Contact details for enquiries
Individual notification should include: - What happened - What information was involved - What you are doing about it - What they can do to protect themselves - Who to contact for more information
Communication strategy: - Prepare media statements if public awareness is likely - Brief key stakeholders (board, investors, partners) - Train customer service to handle enquiries - Monitor social media for public discussion
Phase 5: Remediation (1-12 weeks)
Technical remediation: - Remove attacker access - Patch vulnerabilities that enabled the breach - Restore systems from clean backups - Implement additional security controls - Verify system integrity
Process remediation: - Update policies and procedures - Improve detection capabilities - Enhance monitoring and alerting - Address root causes (not just symptoms)
People remediation: - Additional security awareness training - Role changes if insider threat - Support for affected individuals (credit monitoring, etc.)
Phase 6: Post-Incident Review (4-12 weeks after)
Conduct a thorough post-incident review:
- What happened? Timeline reconstruction
- What went well? Effective response actions
- What went poorly? Gaps in response capability
- What can we improve? Specific recommendations
- What are we doing about it? Action plan with owners and deadlines
MSP Roles and Responsibilities
In Your Contract
Your MSP contract should explicitly define:
- Notification obligations — who notifies the OAIC, who notifies affected parties
- Investigation responsibilities — who conducts forensic analysis
- Cost allocation — who bears the costs of breach response and remediation
- Cooperation requirements — how the MSP will support your response
- Insurance coordination — how cyber insurance claims are managed
The MSP's Obligations
Your MSP should: - Detect and alert you to incidents promptly - Preserve forensic evidence - Provide technical expertise for investigation and remediation - Support your notification obligations - Cooperate with external investigators - Implement corrective actions to prevent recurrence
Your Obligations
As the data controller, you are ultimately responsible for: - OAIC notification - Individual notification - Regulatory compliance - Business decisions during the incident - Post-incident improvements
Testing Your Response Plan
A plan that has never been tested is a plan that will fail. Test annually at minimum:
Tabletop exercises: Walk through a simulated breach scenario with all stakeholders. Test decision-making, communication, and coordination.
Technical drills: Simulate the technical aspects of containment and recovery. Verify that backup restoration works, that monitoring detects the simulated attack, and that containment procedures are effective.
Communication tests: Verify that notification templates are current, that contact lists are accurate, and that communication channels work.
Related Guides
- MSP Cybersecurity Awareness Training — Prevent breaches through training
- MSP Remote Work Security Guide — Security controls for distributed teams
- Cyber Insurance MSP Requirements — Insurance coverage for breaches
- MSP Compliance Framework Guide — Compliance requirements
- MSP Supply Chain Risk — Third-party breach risks
Was this helpful?