Incident Response SOP for Trades & Construction

# Incident Response SOP - Trades & Construction

## Purpose
Ensure your team knows exactly what to do during a crisis to minimise damage, communicate effectively, and recover quickly.

## When to Use
A procedure for responding to security breaches, system outages, or critical business incidents with notification chains, containment steps, and post-incident review.

## Instructions
1. Review the template below and familiarise yourself with the structure
2. Replace all [bracketed placeholders] with your trades & construction business details
3. Customise the tone and formatting to match your brand
4. Save in your preferred tool (Slack or Asana)

---

## Incident Response Standard Operating Procedure

### 1. Purpose and Scope
This SOP defines the standard procedure for responding to security breaches, system outages, data loss events, and other critical business disruptions. Its purpose is to minimise damage, protect client data, maintain stakeholder confidence, and restore normal operations as quickly as possible. This procedure applies to all incidents that impact business operations, customer service, or data security.

### 2. Roles and Responsibilities
- **Incident Commander (IC):** Takes overall ownership of the incident response. Typically the IT Lead, Operations Manager, or most senior person available. Makes decisions on containment and communication.
- **Technical Lead:** Leads the technical investigation and fix. Reports to the Incident Commander.
- **Communications Lead:** Manages all internal and external communications during the incident. Typically the Account Manager or Marketing Lead.
- **All Staff:** Responsible for reporting suspected incidents immediately and following IC instructions during a response.

### 3. Prerequisites
- Slack channel #incidents created and accessible to all staff
- Incident response contact list (with mobile numbers) documented in Notion and printed at reception
- Asana project template for incident tracking created
- All team members trained on this SOP (annual refresher required)

### 4. Severity Classification

| Severity | Description | Response Time | Example |
|----------|-------------|---------------|---------|
| P1 - Critical | Core systems down, data breach, revenue loss | Immediate (within 15 min) | CRM down, client data exposed, website offline |
| P2 - High | Major degradation, workaround limited | Within 1 hour | Email system down, payment processing failing |
| P3 - Medium | Partial impact, workaround available | Within 4 hours | Single integration failing, reporting delayed |
| P4 - Low | Minor issue, no operational impact | Next business day | Cosmetic bug, non-critical feature unavailable |

### 5. Procedure

**Step 1: Detect and Report**
Any team member who identifies a potential incident must immediately post in #incidents on Slack with: what they observed, when they noticed it, and what systems appear affected. For suspected data breaches, also call the Incident Commander directly. Do not attempt to fix the issue independently unless the fix is obvious and low-risk.

**Step 2: Classify and Activate**
The Incident Commander classifies the severity within 15 minutes of the report. For P1 and P2 incidents, the IC creates a dedicated Slack channel (#incident-[date]-[brief-name]) and assembles the response team via direct message and phone calls. For P3/P4, the IC assigns the issue through standard support channels.

**Step 3: Contain the Incident**
The Technical Lead takes immediate action to prevent the incident from worsening. Actions may include: isolating affected systems, revoking compromised access credentials, switching to backup systems, or rolling back recent changes. Every containment action must be documented in the incident Slack channel with a timestamp.

**Step 4: Assess Impact**
Determine: how many customers are affected, what data may have been compromised, what revenue is at risk, and what the regulatory implications are (especially for personal information under the Privacy Act 1988). Report the assessment to the Incident Commander.

**Step 5: Communicate**
The Communications Lead sends the first stakeholder update within 30 minutes of P1/P2 classification:
- **Internal team:** Slack announcement with known facts and instructions
- **Affected clients:** Email using the incident notification template
- **Management/Board:** Direct communication from IC with impact assessment
Commit to regular updates (every 30 minutes for P1, every 2 hours for P2) until resolution.

**Step 6: Investigate and Resolve**
The Technical Lead investigates the root cause while containment measures hold. Once identified, implement the fix with a peer review. Test the fix before full deployment. For P1 incidents, maintain a running timeline of all actions in the incident channel.

**Step 7: Verify Resolution**
Confirm the incident is fully resolved. Ask the original reporter and affected users to verify. Monitor for recurrence for a minimum of 2 hours (P1) or 1 hour (P2). Only the IC can declare the incident resolved.

**Step 8: Send Resolution Notice**
The Communications Lead notifies all stakeholders that the incident is resolved. Include: what happened, what was done, any customer action required, and how recurrence will be prevented.

**Step 9: Notifiable Data Breach Assessment**
If personal information was involved, the IC and Communications Lead must assess whether the breach is notifiable under the Notifiable Data Breaches (NDB) scheme. If notifiable, report to the Office of the Australian Information Commissioner (OAIC) within 30 days and notify affected individuals.

**Step 10: Post-Incident Review**
Within 5 business days, the IC conducts a blameless post-incident review with the response team. Document: full timeline, root cause, what went well, what could be improved, and specific actions to prevent recurrence. File the report in Notion and create follow-up tasks in Asana.

### 6. Escalation Path
1. First responder reports to #incidents
2. Incident Commander classifies and leads response
3. Director notified for all P1 and P2 incidents
4. External consultants engaged if the team cannot resolve within 4 hours (P1) or 24 hours (P2)

### 7. Revision History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | [Date] | [Author] | Initial release |

### 8. Related Documents
- Incident Contact List
- Incident Communication Templates
- Data Breach Response Plan
- Business Continuity Plan
- IT Disaster Recovery Plan

---

**Complexity:** advanced | **Setup time:** 30 minutes | **Tools:** Slack, Asana, Notion

Note: This template has been tailored for trades & construction businesses in Australia. Adjust terminology and compliance references to match your specific context.