Incident Response Plan

Last Updated: July 5, 2026 | Effective Date: July 5, 2026

1. Purpose and Scope

This Incident Response Plan (IRP) establishes the procedures for detecting, responding to, and recovering from security incidents affecting ShambaCare's information systems and user data. This plan applies to all employees, contractors, and third parties with access to ShambaCare systems.

2. Incident Definition

A security incident is an event that compromises the confidentiality, integrity, or availability of information assets. Examples include:

Unauthorized access to user data or systems
Data breach or unauthorized disclosure of personal information
Ransomware or malware infection
Denial of service attacks
Phishing or social engineering attacks
Loss or theft of equipment containing sensitive data
System compromise or unauthorized configuration changes

3. Incident Response Team

3.1 Incident Response Team (IRT) Structure

The IRT consists of the following roles:

Incident Response Lead: Overall coordination and decision-making
Security Analyst: Technical investigation and containment
IT Operations: System recovery and restoration
Legal Counsel: Legal guidance and regulatory compliance
Communications: Internal and external communications
Data Protection Officer: Data privacy and breach notification

3.2 Contact Information

IRT members can be reached at:

Emergency Contact: shambacare@proton.me
24/7 Hotline: [To be configured]

4. Incident Classification

4.1 Severity Levels

Incidents are classified by severity:

Severity	Description	Response Time
Critical	System-wide outage, massive data breach, active attack	Immediate (within 1 hour)
High	Significant data exposure, service disruption	Within 4 hours
Medium	Limited data exposure, partial service impact	Within 24 hours
Low	Minor security issue, no data exposure	Within 72 hours

5. Incident Response Phases

5.1 Phase 1: Preparation

Ongoing activities to ensure readiness:

Maintain up-to-date incident response procedures
Conduct regular security awareness training
Deploy monitoring and detection tools
Establish communication channels
Perform incident response drills quarterly

5.2 Phase 2: Detection and Analysis

5.2.1 Detection Methods

Incidents may be detected through:

Automated monitoring and alerting systems
User reports and help desk tickets
Third-party notifications (e.g., users, partners)
Security audits and assessments
Media reports or public disclosures

5.2.2 Initial Assessment

Upon detection, the IRT will:

Verify the incident and assess scope
Classify severity level
Determine affected systems and data
Identify potential impact on users
Escalate to appropriate team members

5.3 Phase 3: Containment

5.3.1 Containment Strategies

Immediate actions to limit damage:

Isolate affected systems from the network
Disable compromised user accounts
Block malicious IP addresses or domains
Change passwords for affected accounts
Temporarily suspend affected services

5.3.2 Containment Decision

The IRT Lead will decide between:

Short-term containment: Quick actions to stop the incident
Long-term containment: Permanent fixes to prevent recurrence

5.4 Phase 4: Eradication

Actions to remove the threat:

Identify and remove malware or malicious code
Eliminate unauthorized access points
Patch vulnerabilities that were exploited
Rebuild compromised systems from clean backups
Update security configurations

5.5 Phase 5: Recovery

Restoring normal operations:

Restore systems from clean backups
Verify system integrity and functionality
Monitor for signs of recurrence
Gradually restore services to users
Document lessons learned

5.6 Phase 6: Post-Incident Activity

5.6.1 Documentation

Complete incident documentation includes:

Timeline of events and actions taken
Root cause analysis
Impact assessment (data affected, users impacted)
Costs incurred (response, recovery, notification)
Recommendations for improvement

5.6.2 Lessons Learned

Post-incident review meeting will:

Evaluate response effectiveness
Identify areas for improvement
Update incident response procedures
Implement additional security measures
Share findings with relevant stakeholders

6. Communication Procedures

6.1 Internal Communication

Internal stakeholders are informed based on severity:

IT Staff: Immediate notification for technical response
Management: Within 2 hours for high/critical incidents
All Staff: As needed for service disruptions

6.2 External Communication

6.2.1 User Notification

Affected users are notified:

Within 72 hours of discovery for data breaches
As required by applicable laws and regulations
Via email, in-app notification, or website notice
With clear information about the incident and impact

6.2.2 Regulatory Notification

Regulatory authorities are notified:

Office of the Data Protection Commissioner (Kenya) within 72 hours
Other relevant authorities as required by law
With detailed incident report and remediation steps

6.2.3 Media Communication

Public statements are handled by:

Designated spokesperson only
Approved messaging from legal counsel
Factual, timely, and transparent communication

7. Specific Incident Scenarios

7.1 Data Breach

Specific procedures for data breaches:

Identify what data was exposed and to whom
Determine if data was encrypted or protected
Assess risk to affected individuals
Notify affected users with remediation guidance
Offer credit monitoring or identity theft protection if applicable

7.2 Ransomware Attack

Specific procedures for ransomware:

Isolate infected systems immediately
Do not pay ransom without legal consultation
Restore from offline backups if available
Report to law enforcement if appropriate
Conduct thorough forensic analysis

7.3 Phishing Attack

Specific procedures for phishing:

Identify all users who received the phishing email
Reset credentials for compromised accounts
Block sender domain and similar domains
Analyze phishing email for indicators of compromise
Educate affected users on identifying phishing

7.4 Denial of Service

Specific procedures for DoS/DDoS:

Implement rate limiting and traffic filtering
Engage DDoS mitigation service if available
Scale infrastructure to absorb attack traffic
Communicate with users about service disruption
Identify attack source for potential legal action

8. Reporting Procedures

8.1 Incident Reporting

All personnel must report suspected incidents:

Immediately upon discovery
To the IRT via email: shambacare@proton.me
With as much detail as possible (what, when, where, how)
Without attempting to investigate personally

8.2 Whistleblower Protection

ShambaCare protects whistleblowers who:

Report security concerns in good faith
Cooperate with incident investigations
Report through established channels

Retaliation against whistleblowers is prohibited.

9. Training and Awareness

9.1 IRT Training

IRT members receive specialized training on:

Incident response procedures and tools
Forensic investigation techniques
Legal and regulatory requirements
Communication and crisis management

9.2 General Staff Training

All staff receive training on:

Recognizing and reporting security incidents
Phishing and social engineering awareness
Data handling best practices
Incident response procedures overview

10. Testing and Drills

10.1 Tabletop Exercises

Quarterly tabletop exercises to:

Test incident response procedures
Identify gaps in the plan
Train IRT members
Evaluate communication procedures

10.2 Simulated Incidents

Annual simulated incident to:

Test full incident response lifecycle
Evaluate technical detection and response
Measure response times
Identify areas for improvement

11. Plan Maintenance

This Incident Response Plan is:

Reviewed annually by the IRT and management
Updated after significant incidents
Revised to reflect changes in technology or threats
Approved by senior management

12. Legal and Regulatory Considerations

This plan is designed to comply with:

Kenya Data Protection Act, 2019 (72-hour breach notification)
Kenya Computer Misuse and Cybercrimes Act, 2018
GDPR (for EU data subjects)
Industry-specific agricultural regulations

13. Contact Information

For incident reporting or questions about this plan:

Incident Response Team: shambacare@proton.me
Data Protection Officer: shambacare@proton.me
Address: Taveta Sub-County, Taita Taveta County - Kenya

14. Appendix: Incident Response Checklist

Initial Response Checklist

[ ] Verify incident and assess scope
[ ] Classify severity level
[ ] Notify IRT Lead
[ ] Document initial findings
[ ] Begin containment procedures

Containment Checklist

[ ] Isolate affected systems
[ ] Disable compromised accounts
[ ] Block malicious IPs/domains
[ ] Change affected passwords
[ ] Preserve evidence for forensics

Eradication Checklist

[ ] Remove malware or malicious code
[ ] Patch exploited vulnerabilities
[ ] Rebuild compromised systems
[ ] Update security configurations
[ ] Verify threat is eliminated

Recovery Checklist

[ ] Restore from clean backups
[ ] Verify system integrity
[ ] Monitor for recurrence
[ ] Gradually restore services
[ ] Update documentation

Post-Incident Checklist

[ ] Complete incident report
[ ] Conduct root cause analysis
[ ] Hold lessons learned meeting
[ ] Update procedures as needed
[ ] Notify affected stakeholders