Incident Response

Security incident response procedures and playbooks for MDHosting Ltd.

Critical Operational Document

This documentation provides execution-ready procedures for responding to security incidents. All staff must be familiar with these procedures and respond according to the severity levels defined herein.

Overview

This document establishes comprehensive incident response procedures for MDHosting Ltd. It complements our GDPR Compliance documentation, providing detailed operational guidance for detecting, responding to, and recovering from security incidents.

Purpose: - Provide clear, actionable procedures for incident response - Ensure compliance with UK GDPR breach notification requirements (72-hour ICO deadline) - Minimise impact to clients and business operations - Enable systematic learning and improvement from incidents

Scope: - All security incidents affecting MDHosting infrastructure, systems, or data - Data breach incidents (with cross-reference to GDPR procedures) - Service availability incidents - Vendor and supply chain security incidents

Relationship to GDPR Breach Procedures:

For personal data breaches specifically, this document provides technical response procedures that integrate with the comprehensive GDPR breach notification requirements documented in GDPR Compliance - Data Breach Notification (lines 1302-1378).

Use this document for: - All incident types (not just data breaches) - Technical response procedures (containment, eradication, recovery) - Incident-specific playbooks (malware, DDoS, unauthorized access, infrastructure failures) - Communication protocols and templates - Post-incident review and improvement

Use GDPR doc for: - Data breach assessment criteria (high risk vs. low risk) - ICO notification requirements and timelines (72-hour deadline) - Data subject notification obligations - Breach register requirements

Single Operator Environment

MDHosting operates as a single operator environment with the Director (Matthew Dinsdale) serving as the primary incident handler. This documentation accounts for this reality by:

Providing clear decision-making guidance without requiring team consensus
Including external escalation procedures for support (Hetzner, cPanel, ICO)
Emphasising documentation for accountability and learning
Balancing thoroughness with practical time constraints
Providing ready-to-use communication templates for rapid response

Incident Response Lifecycle

Incident response follows a structured lifecycle, ensuring systematic and effective handling of security events.

graph TB
    PREP[Preparation<br/>Policies, training, tools] -->|Incident Detected| DETECT[Detection<br/>Identify and classify]
    DETECT -->|Incident Confirmed| CONTAIN[Containment<br/>Stop the damage]
    CONTAIN -->|Threat Contained| ERADICATE[Eradication<br/>Remove threat]
    ERADICATE -->|Threat Removed| RECOVER[Recovery<br/>Restore operations]
    RECOVER -->|Operations Restored| LESSONS[Lessons Learned<br/>Improve processes]
    LESSONS -->|Update Procedures| PREP

    style PREP fill:#3498db,stroke:#2c3e50,stroke-width:3px,color:#fff
    style DETECT fill:#f39c12,stroke:#2c3e50,stroke-width:3px,color:#fff
    style CONTAIN fill:#e74c3c,stroke:#2c3e50,stroke-width:3px,color:#fff
    style ERADICATE fill:#e74c3c,stroke:#2c3e50,stroke-width:3px,color:#fff
    style RECOVER fill:#27ae60,stroke:#2c3e50,stroke-width:3px,color:#fff
    style LESSONS fill:#8e44ad,stroke:#2c3e50,stroke-width:3px,color:#fff

Lifecycle Phases:

Preparation - Implement security controls, train staff, establish procedures (ongoing)
Detection - Identify potential security incidents through monitoring, alerts, or reports
Containment - Prevent further damage, isolate affected systems, protect unaffected systems
Eradication - Remove the threat, close vulnerabilities, eliminate root cause
Recovery - Restore systems and services to normal operations
Lessons Learned - Review incident, document findings, improve procedures

This document provides detailed guidance for each phase.

Incident Definition

A security incident is any event that: - Compromises the confidentiality, integrity, or availability of systems or data - Violates security policies or acceptable use - Threatens business operations or client services - Requires investigation or remediation

Examples of Security Incidents: - Unauthorized access to systems or accounts - Malware infection or ransomware attack - Data breach or unauthorized disclosure of personal data - Denial of Service (DoS/DDoS) attack - Phishing or social engineering attack - System or service outages with security implications - Lost or stolen devices containing sensitive data - Insider threat or policy violation - Vendor security incident affecting our services

Not Typically Incidents: - Routine service maintenance or planned downtime - User errors without security implications - Performance issues without malicious cause - False positive security alerts (after investigation) - Blocked attacks that were successfully prevented

When in Doubt, Escalate

If unsure whether an event constitutes a security incident, treat it as one and follow initial assessment procedures. It is better to investigate and determine no incident occurred than to miss a genuine security event.

Incident Classification System

All incidents must be classified by severity to determine appropriate response timelines and escalation procedures.

Severity Levels

Severity	Definition	Response Time	Examples
Critical	Complete service outage, active attack in progress, confirmed data breach with high risk, or imminent threat to business operations	<1 hour	• All client websites down • Active ransomware encryption • Database compromise with personal data exfiltration • Root access compromise • Ongoing DDoS overwhelming infrastructure
High	Significant service degradation, potential data breach, successful attack with contained scope, or high-risk vulnerability actively exploited	<4 hours	• Single server degraded affecting multiple clients • Malware detected on client accounts • Unauthorized access attempt with partial success • DDoS attack mitigated but ongoing • Critical vulnerability with active exploitation
Medium	Limited service impact, suspicious activity requiring investigation, low-risk data exposure, or security policy violation	<24 hours	• Failed attack attempts with no access gained • Minor malware detected and quarantined • Suspicious login activity • Non-critical vulnerability identified • Single client account compromised
Low	Informational security events, resolved automatically, minimal risk, or long-term security improvements	<72 hours	• Security scan findings • Policy violations (minor) • False positive alerts (confirmed) • Routine security updates required • Audit findings

Impact Assessment Criteria

When classifying incident severity, consider:

1. Data Confidentiality Impact - Is personal data involved? (GDPR implications) - What data categories affected? (Passwords, payment data, personal information) - How many data subjects affected? - Is the data encrypted? - Likelihood of data exfiltration?

2. Service Availability Impact - How many clients affected? - Complete outage or degradation? - Business-critical services impacted? - Revenue impact? - Duration of impact (actual or projected)?

3. Client Business Impact - Are client websites/email down? - Client data compromised? - Client reputation at risk? - SLA breaches? - Financial losses to clients?

4. Regulatory/Compliance Impact - GDPR breach requiring ICO notification? (See GDPR doc) - Other legal or regulatory obligations? - Contractual violations? - Audit or certification impact?

5. Reputational Impact - Public disclosure likely? - Media attention risk? - Client trust affected? - Long-term business impact?

Data Breach Classification

Any incident involving unauthorized access to, disclosure of, or loss of personal data must be assessed against GDPR breach criteria. See GDPR Compliance - Breach Assessment Criteria for detailed guidance on high-risk vs. low-risk determination.

Incident Categories

Incidents are categorised by type to enable use of specific response playbooks:

1. Data Breach - Unauthorized access to personal data - Accidental disclosure or loss of personal data - Exfiltration of client databases or files - See Data Breach Playbook and GDPR procedures

2. Malware/Ransomware - Virus, trojan, or malware infection - Ransomware encryption attack - Cryptomining or botnet activity - See Malware/Ransomware Playbook

3. DDoS/Service Disruption - Denial of Service or Distributed Denial of Service attacks - Network flooding or resource exhaustion - See DDoS Attack Playbook

4. Unauthorized Access - Compromised accounts or credentials - Exploitation of vulnerabilities - Privilege escalation - Insider threat - See Unauthorized Access Playbook

5. Infrastructure Failure - Server hardware failure - Network connectivity loss - Critical service failure (database, web server, email) - See Infrastructure Failure Playbook

6. Vendor/Supply Chain Incident - Hetzner datacenter issues - cPanel vulnerabilities - Third-party service compromise - See Vendor/Supply Chain Playbook

7. Policy Violation - Misuse of systems or data - Unauthorized software installation - Security policy breach

Roles and Responsibilities

Primary Incident Handler

Matthew Dinsdale (Director)

As the single operator for MDHosting Ltd, the Director serves as the primary (and sole) incident handler with full authority and responsibility for:

Incident Detection and Classification - Monitoring alerts, classifying severity, determining response actions
Incident Response Execution - Performing containment, eradication, and recovery procedures
Decision Authority - All incident response decisions including:
Incident severity classification and reclassification
Client notification decisions and timing
ICO breach notification (72-hour GDPR deadline)
Service shutdown or isolation decisions
Vendor escalation and external support requests
Resource allocation and prioritisation
Documentation and Reporting - Maintaining incident logs, breach register, post-incident reports
Communication - Client notifications, ICO communications, vendor escalations
Continuous Improvement - Post-incident reviews, procedure updates, lessons learned

External Support and Escalation

Due to the single operator environment, external support is critical for incident response. The following external parties provide support based on incident type:

Support Provider	Contact Method	When to Escalate	Response SLA
Hetzner Support	Support ticket via Robot panel	• Server hardware failure • Network connectivity issues • DDoS attacks overwhelming infrastructure • Datacenter-level incidents	• Critical: <1 hour • High: <4 hours • Standard: <24 hours
cPanel Support	Support ticket via cPanel account	• Control panel vulnerabilities • Software bugs affecting operations • License or authentication issues	• Critical: <2 hours • Standard: <24 hours
ICO (Information Commissioner's Office)	Online breach reporting form or 0303 123 1113	• Personal data breach requiring notification • Within 72 hours of breach awareness • See GDPR doc	Report within 72 hours
Legal Counsel	Via professional services agreement	• High-risk data breaches • Regulatory investigations • Client legal disputes • Contract violations	As required
Law Enforcement	101 (non-emergency) or 999 (emergency)	• Criminal activity (hacking, fraud) • Threats or extortion • Evidence preservation required	Immediate for emergencies
Client's IT Support	Via client contact details	• Client-side issues requiring joint response • Complex WordPress/application issues • Coordinated recovery efforts	As needed

Complete Contact Information

Full contact details, procedures, and escalation paths are documented in Contacts - Service Providers and Contacts - Regulatory Authorities.

Decision Authority Guidelines

As the single operator, all decisions rest with the Director. However, the following guidelines ensure consistent, appropriate decision-making:

Incident Classification Decisions: - Use severity criteria in Incident Classification System objectively - When uncertain between severity levels, escalate to higher severity - Reclassify severity as new information emerges

Client Notification Decisions: - Critical/High severity: Notify all affected clients immediately - Medium severity: Notify if client services impacted or action required - Low severity: Notify only if client awareness beneficial - Data breaches: Follow GDPR notification requirements (see GDPR doc)

ICO Escalation Decisions: - Any personal data breach: Assess against GDPR criteria immediately - High-risk breaches: ICO notification mandatory within 72 hours - Low-risk breaches: Document in breach register, ICO notification not required - See GDPR Compliance - Breach Assessment Criteria for detailed guidance

Service Shutdown Decisions: - Active attack in progress: Isolate affected systems immediately - Potential data exfiltration: Shut down affected services to prevent further loss - Widespread malware: Isolate infected systems, consider preventative shutdown of at-risk systems - Balance: Weigh security risk against service availability impact

Vendor Escalation Decisions: - Infrastructure issues: Escalate to Hetzner for hardware, network, or datacenter problems - Software vulnerabilities: Escalate to cPanel for control panel issues - Critical severity: Escalate immediately regardless of business hours - High severity: Escalate within response time targets

Detection and Initial Assessment

Detection Sources

Security incidents may be detected through multiple sources. Regular monitoring of these sources enables early detection and rapid response:

1. Automated Security Tools - Fail2Ban - Automated IP banning for brute-force attempts (SSH, cPanel, email, FTP) - Alert source: Email notifications to admin@mdhosting.co.uk - Log location: /var/log/fail2ban.log - CSF (ConfigServer Security & Firewall) - Intrusion detection and firewall management - Alert source: Email notifications and login failure tracking (LFD) - Log location: /var/log/lfd.log - ClamAV/Maldet - Malware scanning (when scheduled scans run) - Alert source: Scan result emails - Log locations: /var/log/clam*, /usr/local/maldetect/logs/

2. System and Service Logs - System logs: /var/log/messages, /var/log/secure - Web server logs: /usr/local/apache/logs/error_log, /usr/local/apache/domlogs/ - Email logs: /var/log/exim_mainlog, /var/log/exim_rejectlog - cPanel logs: /usr/local/cpanel/logs/access_log, /usr/local/cpanel/logs/error_log - Database logs: /var/lib/mysql/*.err (MySQL error logs)

3. Client Reports - Support tickets via Blesta (https://mdhosting.co.uk/billing) - Direct email to support@mdhosting.co.uk - Phone calls (when client contact details provided) - Client reports often first indication of service disruption or compromise

4. External Notifications - Hetzner - Datacenter issues, DDoS mitigation, abuse reports - Third-party monitoring - When clients use external uptime monitoring - Security researchers - Vulnerability disclosures

5. Wazuh SIEM (Planned Q1 2025) - Centralised security event monitoring and alerting - Real-time threat detection and correlation - See Wazuh Deployment Plan for implementation timeline

Initial Assessment Procedure

Upon detecting a potential security incident, perform the following 7-step assessment immediately to determine severity and appropriate response:

Step 1: Confirm the Incident (2-5 minutes) - Verify the alert is not a false positive - Gather initial evidence from logs or monitoring tools - Determine if this is a security incident or routine event - If confirmed incident, proceed to Step 2

Step 2: Classify Incident Severity (2-5 minutes) - Use Severity Levels criteria - Consider impact on data confidentiality, service availability, clients - Assign initial severity: Critical, High, Medium, or Low - Start response timer based on severity response time target

Step 3: Categorise Incident Type (1-2 minutes) - Identify incident category from Incident Categories - Select appropriate playbook for detailed response procedures - Note: Multiple categories may apply (e.g., malware leading to data breach)

Step 4: Assess Immediate Risk (3-5 minutes) - Is an attack currently in progress? (Active vs. historic incident) - What systems/services are affected or at risk? - How many clients are impacted? - Is personal data involved? (GDPR implications - see Step 7) - Is there risk of further damage or data loss?

Step 5: Preserve Evidence (5-10 minutes) - Before any remediation actions, preserve evidence for investigation - See Evidence Preservation below for specific commands - Take snapshots, copy logs, document system state - Evidence required for forensics, compliance, and learning

Step 6: Create Incident Log (2-3 minutes) - Create incident log file: INC-YYYY-MM-DD-### (e.g., INC-2026-01-15-001) - Document: Detection time, detection source, initial classification, affected systems - Maintain timeline throughout incident (all actions, decisions, findings) - See Incident Documentation for template

Step 7: GDPR Breach Determination (2-5 minutes) - If personal data involved, assess breach severity immediately - High-risk breach: ICO notification required within 72 hours - Low-risk breach: Document in breach register, no ICO notification required - See GDPR Compliance - Breach Assessment Criteria - Start 72-hour countdown timer if ICO notification required

Critical Time Limits

Critical incidents: Complete initial assessment within 15 minutes, begin containment immediately
High incidents: Complete initial assessment within 30 minutes
GDPR breaches: 72-hour ICO notification deadline starts from awareness (Step 7 completion)

Evidence Preservation Commands

Before making any changes to affected systems, preserve evidence using these commands. Evidence is critical for investigation, regulatory compliance, and post-incident analysis.

System State Snapshot:

# Capture current system state
date > /root/incidents/INC-YYYY-MM-DD-###/timestamp.txt
uptime >> /root/incidents/INC-YYYY-MM-DD-###/system-state.txt
ps auxf >> /root/incidents/INC-YYYY-MM-DD-###/processes.txt
netstat -tulpn >> /root/incidents/INC-YYYY-MM-DD-###/network-connections.txt
last -f /var/log/wtmp >> /root/incidents/INC-YYYY-MM-DD-###/login-history.txt

Log Preservation:

# Create incident evidence directory
mkdir -p /root/incidents/INC-YYYY-MM-DD-###/logs/

# Copy relevant logs (adjust based on incident type)
cp /var/log/messages* /root/incidents/INC-YYYY-MM-DD-###/logs/
cp /var/log/secure* /root/incidents/INC-YYYY-MM-DD-###/logs/
cp /var/log/fail2ban.log* /root/incidents/INC-YYYY-MM-DD-###/logs/
cp /usr/local/apache/logs/error_log /root/incidents/INC-YYYY-MM-DD-###/logs/
cp /var/log/exim_mainlog /root/incidents/INC-YYYY-MM-DD-###/logs/

Database Evidence (if applicable):

# List databases and users
mysql -e "SHOW DATABASES;" > /root/incidents/INC-YYYY-MM-DD-###/databases.txt
mysql -e "SELECT user,host FROM mysql.user;" > /root/incidents/INC-YYYY-MM-DD-###/db-users.txt

File Integrity Check:

# Generate file checksums for affected directories
find /home/username/public_html -type f -exec md5sum {} \; > /root/incidents/INC-YYYY-MM-DD-###/file-checksums.txt

Evidence Retention

Evidence must be retained for: - GDPR breaches: Minimum 3 years (regulatory requirement) - Other incidents: Minimum 1 year (operational requirement) - Storage location: /root/incidents/ on EU1 server, backed up offsite

Incident Response Procedures

After completing initial assessment and evidence preservation, execute the incident response using the three-phase approach: Containment (stop the damage), Eradication (remove the threat), and Recovery (restore normal operations).

Containment Phase

Goals: - Stop the incident from causing further damage - Prevent spread to additional systems or data - Maintain evidence for investigation - Minimise service disruption where possible

Containment Actions by Incident Type:

Incident Type	Immediate Containment Actions	Considerations
Data Breach	• Disable compromised accounts • Block unauthorized access (firewall rules, password changes) • Isolate affected database or file system • Preserve access logs	GDPR 72-hour notification clock is running
Malware/Ransomware	• Isolate infected systems (network isolation) • Disable affected accounts • Block malware C&C domains (firewall) • Prevent lateral spread	DO NOT pay ransom - restore from backups
DDoS Attack	• Enable CSF rate limiting • Block attacking IPs (automated via CSF/Fail2Ban) • Contact Hetzner for upstream mitigation • Activate DDoS mitigation if available	Balance mitigation with legitimate traffic
Unauthorized Access	• Terminate active sessions • Change all passwords (SSH, cPanel, databases) • Disable compromised accounts • Block attacker IPs	Consider full system compromise scenario
Infrastructure Failure	• Failover to redundant systems (if available) • Engage Hetzner for hardware issues • Activate backup services • Communicate ETA to clients	Single server = single point of failure
Vendor Incident	• Assess impact to our services • Implement compensating controls • Monitor vendor status updates • Prepare client communications	Limited control - vendor dependent

Short-Term vs. Long-Term Containment:

Short-term containment (minutes to hours): Quick actions to stop immediate damage (block IPs, disable accounts, isolate systems)
Long-term containment (hours to days): Sustainable containment allowing partial operations while planning eradication (temporary workarounds, monitoring, client communication)

Eradication Phase

Goal: Completely remove the threat and close the vulnerability that allowed the incident.

Eradication Steps:

Identify Root Cause (30-60 minutes)
Analyze evidence to determine how the incident occurred
Identify vulnerabilities, misconfigurations, or compromised credentials
Document attack vector and timeline reconstruction
Remove Threats (varies by incident)
Malware: Remove malicious files, processes, and persistence mechanisms
Unauthorized access: Audit all accounts, keys, and access permissions
Vulnerabilities: Apply patches, update software, fix configurations
Data breach: Ensure unauthorized access has been terminated
Close Vulnerabilities (30 minutes - 4 hours)
Patch software vulnerabilities (cPanel, WordPress, plugins, system packages)
Fix configuration errors (file permissions, firewall rules, service configs)
Remove backdoors or unauthorized access methods
Strengthen access controls (enforce strong passwords, 2FA where possible)
Verify Eradication (30-60 minutes)
Re-scan systems for malware (ClamAV, Maldet)
Verify no unauthorized access remains (audit logs, active sessions)
Confirm vulnerabilities are closed (security scans, manual checks)
Document verification results in incident log
Implement Additional Controls (optional, varies)
Add monitoring rules to detect recurrence
Implement additional firewall rules
Enable additional logging or alerting
Consider architectural changes to prevent recurrence

Complete Eradication Required

Do not proceed to recovery until eradication is complete and verified. Restoring services before removing the threat will result in immediate re-compromise.

Recovery Phase

Goal: Restore systems and services to normal operations while maintaining security.

Recovery Checklist:

1. System Restoration - [ ] Restore affected services from clean backups (if required) - [ ] Rebuild compromised systems from clean images (if complete compromise) - [ ] Restore data from verified clean backups - [ ] Verify system integrity after restoration (file checksums, security scans)

2. Security Validation - [ ] All passwords changed (system, cPanel, databases, applications) - [ ] All unauthorized access removed and verified - [ ] Vulnerabilities patched and tested - [ ] Security controls functioning (firewall, Fail2Ban, monitoring) - [ ] No malware detected (full system scan)

3. Service Restoration - [ ] Start services in controlled manner (monitor for issues) - [ ] Test critical functionality (websites, email, databases) - [ ] Monitor for anomalies (unusual traffic, errors, performance issues) - [ ] Verify client services operational - [ ] Measure service restoration time (for metrics)

4. Enhanced Monitoring - [ ] Increase logging verbosity temporarily - [ ] Monitor for recurrence indicators (same attack patterns, IPs, techniques) - [ ] Review logs daily for first week after incident - [ ] Set alerts for suspicious activity related to incident

5. Client Communication - [ ] Notify clients of service restoration (if they were notified of incident) - [ ] Provide incident summary and remediation actions taken - [ ] Advise on any actions clients need to take (password changes, security checks) - [ ] For data breaches: Follow GDPR data subject notification requirements

Post-Incident Activities Timeline

After recovery, complete the following activities according to the specified timeline:

Within 24 Hours of Resolution: - Complete incident log with full timeline and all actions taken - Update breach register if GDPR breach occurred - Initial lessons learned capture (what worked, what didn't) - Notify affected clients of resolution (if they were notified of incident)

Within 72 Hours of Resolution: - ICO breach notification submitted (if high-risk GDPR breach - see GDPR doc) - Vendor notifications completed (if vendor involvement required) - Interim incident report to management/stakeholders

Within 1 Week of Resolution: - Conduct post-incident review meeting (even if single operator - structured self-review) - Complete detailed post-incident report (see Post-Incident Review) - Identify process improvements and assign actions - Update documentation if procedures need refinement

Within 2 Weeks of Resolution: - Implement quick-win improvements identified in review - Update security controls based on lessons learned - Schedule long-term improvements (if architectural or system changes needed)

Within 1 Month of Resolution: - Complete all remediation actions from lessons learned - Update incident response procedures based on experience - Conduct tabletop exercise for similar incident scenario (test improvements) - Archive incident documentation for long-term retention

Incident-Specific Playbooks

The following playbooks provide detailed response procedures for specific incident types. Use these in conjunction with the general Incident Response Procedures above.

Data Breach Playbook

Scope: Unauthorized access to, disclosure of, or loss of personal data.

GDPR 72-Hour Deadline

The 72-hour ICO notification deadline starts when you become aware of the breach, not when the breach occurred. Time is critical.

Special Considerations for Data Breaches:

Data breach incidents require compliance with UK GDPR breach notification requirements in addition to technical incident response procedures. This playbook provides supplementary technical steps; for complete GDPR breach procedures, see GDPR Compliance - Data Breach Notification (lines 1302-1378).

Integrated Response Timeline:

Timeframe	Technical Response (This Playbook)	GDPR Compliance (GDPR Doc)
0-1 hour	• Preserve evidence • Contain breach (disable access) • Assess scope of compromise	• Assess GDPR breach criteria • Start 72-hour countdown • Document breach in register
1-24 hours	• Complete containment • Begin eradication • Analyze affected data categories and subjects	• Determine high-risk vs. low-risk • Prepare ICO notification draft • Identify affected data subjects
24-72 hours	• Complete eradication • Verify no ongoing access • Begin recovery	• Submit ICO notification (if high-risk) • Prepare data subject notifications
Post-72 hours	• Restore normal operations • Enhanced monitoring • Post-incident review	• Data subject notifications (if required) • ICO follow-up information • Update breach register

Additional Technical Steps for Data Breaches:

Determine Exact Data Compromised - Essential for GDPR assessment
What data categories? (names, emails, passwords, payment data, etc.)
How many data subjects affected?
Is data encrypted or otherwise protected?
Likelihood of actual exfiltration vs. potential access?
Assess Data Sensitivity - Impacts breach classification
Special category data? (health, biometric, genetic, racial/ethnic origin, etc.)
Children's data involved?
Financial or payment data?
Authentication credentials (passwords, API keys)?
Document Data Flow - Required for ICO notification
How was data accessed or disclosed?
What systems were involved?
Duration of unauthorized access?
Has unauthorized access been terminated?

Cross-Reference to GDPR Procedures: - Breach Assessment Criteria - Determine high-risk vs. low-risk - ICO Notification Procedure - 72-hour deadline and submission process - Data Subject Notification - When and how to notify affected individuals - Breach Register - Documentation requirements

Malware/Ransomware Playbook

Scope: Virus, trojan, malware infection, ransomware encryption, cryptomining, or botnet activity.

Detection Indicators: - ClamAV/Maldet scan alerts - Unusual CPU or network usage (cryptomining, botnet C&C) - Modified files or new unknown files in web directories - Client reports of website defacement or malicious content - Ransomware notes or encrypted files (extension changes, ransom messages)

Immediate Actions (First 15 Minutes):

Isolate Infected System(s) - Priority #1 to prevent spread

# For cPanel account isolation - suspend account
/scripts/suspendacct username "Security incident - malware detected"

# For system-wide infection - consider network isolation
# Block outbound traffic from server (if safe to do so)

Identify Malware Type
Ransomware: Look for ransom notes, file extensions changed, encryption activity
Web shell: Check for unauthorized PHP/CGI files in web directories
Cryptominer: Check processes for high CPU usage (top, htop)
Botnet: Check for unusual outbound connections (netstat -tulpn)
Preserve Evidence
Copy malicious files to incident directory before deletion
Capture process list and network connections
Preserve relevant logs (access logs showing initial infection vector)

Containment: - Disable affected cPanel accounts to prevent further malware execution - Block malware command-and-control (C&C) domains in firewall - If server-wide infection, consider full service isolation (impact vs. risk decision)

Eradication:

Scan for Malware

# Full ClamAV scan
clamscan -r -i --remove /home/username/

# Maldet scan
maldet -a /home/username/public_html/

Manual Malware Removal - Automated scans don't catch everything
Check common injection points: .htaccess, index.php, wp-config.php
Look for recently modified files: find /home/username/ -mtime -7 -type f
Check for suspicious files: find /home/username/public_html -name "*.suspected"
Review cron jobs for persistence: crontab -l -u username
Identify Infection Vector
Outdated WordPress/plugins? Check versions and update
Weak passwords? Enforce password reset
Vulnerable script? Remove or patch
File upload vulnerability? Review upload permissions and validation
Close Vulnerability - Critical to prevent reinfection
Update all software (WordPress core, plugins, themes)
Fix file permissions (no 777 permissions on web-accessible files)
Remove unused plugins/themes
Implement additional security controls (plugin firewalls, etc.)

Ransomware-Specific Steps:

DO NOT Pay Ransom

MDHosting policy: Never pay ransomware demands. Restore from backups instead.

Assess Encryption Scope
What files are encrypted? (check file extensions, attempt to open files)
What systems are affected? (client account only vs. server-wide)
Are backups affected? (check backup integrity immediately)
Ransomware Identification
Identify ransomware variant (search ransom note text online)
Check for free decryption tools (No More Ransom project: nomoreransom.org)
Document ransomware details for law enforcement
Restore from Backups
Verify backup integrity and cleanliness (scan backups for malware)
Restore from most recent clean backup (pre-encryption)
Test restored data before bringing back online

Recovery: - Restore affected account from clean backup if complete cleanup not possible - Change all passwords (cPanel, FTP, database, application admin) - Re-scan after restoration to ensure no reinfection - Monitor for 48-72 hours with enhanced logging

DDoS Attack Playbook

Scope: Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks causing service degradation or outage.

Detection Indicators: - High bandwidth usage or server load (check uptime, top, bandwidth graphs in Hetzner Robot) - Large number of connections from same IPs or IP ranges - CSF/LFD alerts for connection flooding - Client reports of slow or unavailable websites - Hetzner DDoS mitigation notifications

Immediate Actions (First 10 Minutes):

Confirm DDoS Attack

# Check current connections and identify attacking IPs
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20

# Check server load
uptime
top

Enable Rate Limiting

# CSF connection tracking and rate limiting (adjust limits as needed)
# Edit /etc/csf/csf.conf:
# CT_LIMIT = "100" (connections per IP)
# CT_INTERVAL = "30" (time interval in seconds)

# Restart CSF to apply
csf -r

Block Attacking IPs - If identifiable source IPs

# Block specific IP
csf -d 1.2.3.4 "DDoS attack"

# Block IP range (CIDR notation)
csf -d 1.2.3.0/24 "DDoS attack range"

Containment:

Level 1: CSF Rate Limiting (for small-scale attacks) - Enable connection tracking and rate limiting in CSF - Block identified attacking IPs automatically via Fail2Ban rules - Monitor server load - if this controls the attack, maintain and monitor

Level 2: Hetzner DDoS Mitigation (for larger attacks) - Contact Hetzner support via Robot panel (https://robot.hetzner.com) - Request DDoS mitigation activation - Provide: Attack start time, affected IPs, attack type (if known) - Hetzner response SLA: Critical <1 hour, High <4 hours

Level 3: Service Isolation (last resort for overwhelming attacks) - If attack targets specific site, isolate that account/domain - Implement temporary DNS changes to redirect traffic - Consider temporary service shutdown to protect infrastructure

DDoS Mitigation Techniques:

Technique	When to Use	How to Implement
Rate Limiting	Small-scale attacks, identifiable patterns	CSF CT_LIMIT configuration
IP Blocking	Attack from limited IP ranges	CSF deny rules, Fail2Ban
SYN Cookie Protection	SYN flood attacks	Enable in kernel: `sysctl -w net.ipv4.tcp_syncookies=1`
Connection Limits	HTTP flood attacks	Apache MaxClients, mod_evasive
Upstream Mitigation	Large-scale DDoS overwhelming bandwidth	Hetzner DDoS mitigation service

Communication During Attack:

Clients: Notify affected clients of ongoing attack and mitigation efforts
Hetzner: Escalate to Hetzner for attacks exceeding local mitigation capacity
Updates: Provide regular status updates (every 2-4 hours for critical, daily for high severity)

Recovery: - Gradually remove rate limiting once attack subsides (monitor for resurgence) - Analyze attack patterns and implement permanent blocks for attacking networks if appropriate - Document attack details (IPs, timing, techniques) for future reference

Unauthorized Access Playbook

Scope: Compromised accounts, credential theft, exploitation of vulnerabilities, privilege escalation, insider threats.

Detection Indicators: - Fail2Ban/CSF alerts for successful login from unusual location or IP - Unknown SSH keys in ~/.ssh/authorized_keys - Unexpected sudo/root activity in /var/log/secure - Modified system files or configurations - New user accounts not created by administrator - cPanel login from unexpected IPs (check /usr/local/cpanel/logs/access_log)

Immediate Actions (First 10 Minutes):

Terminate Active Sessions

# List active sessions
who
w

# Kill specific user session
pkill -KILL -u username

# For SSH sessions specifically
ps aux | grep sshd
kill [PID]

Change All Passwords Immediately

# Change root password
passwd

# Change cPanel account password
/scripts/realchpass username newpassword

# Force MySQL password change
mysql -e "SET PASSWORD FOR 'username'@'localhost' = PASSWORD('newpass');"

Disable Compromised Accounts - Until full audit complete

# Disable cPanel account
/scripts/suspendacct username "Security incident - unauthorized access"

# Disable system user
passwd -l username

Containment:

Audit All Access Methods
SSH keys: Check /root/.ssh/authorized_keys and all user ~/.ssh/authorized_keys
Passwords: Force password change for all accounts (system, cPanel, databases)
cPanel API tokens: Revoke and regenerate if in use
Application credentials: Review WordPress admin users, other CMS accounts

Block Attacker IPs

# Block IPs used for unauthorized access
csf -d attacker.ip.address "Unauthorized access attempt"

Review and Remove Unauthorized Changes
New user accounts: cat /etc/passwd - look for unknown users with UID > 1000
Sudo privileges: cat /etc/sudoers and /etc/sudoers.d/*
Cron jobs: crontab -l for root and all users
SSH configuration: /etc/ssh/sshd_config - ensure no backdoor configs

Eradication:

Identify Initial Access Vector
Brute force attack? (Check /var/log/secure for repeated failed attempts then success)
Stolen credentials? (No failed attempts, direct successful login)
Vulnerability exploitation? (Check web server logs around timeframe)
Phishing or social engineering? (Unusual but possible)
Remove Backdoors and Persistence Mechanisms
Check for web shells in web directories (see Malware Playbook)
Review startup scripts: /etc/rc.local, /etc/systemd/system/, /etc/init.d/
Check for rootkits: rkhunter --check or chkrootkit
Audit SSH authorized_keys files across all accounts
Close Vulnerabilities
If brute force: Implement SSH key authentication, disable password auth
If weak password: Enforce strong password policy
If software vulnerability: Patch affected software immediately
If compromised key/credential: Rotate all keys and credentials
Full System Audit (for root/system compromise)
Check system binaries for modifications: rpm -Va (RPM-based systems)
Review system logs for attacker activities and scope of compromise
Consider full server rebuild if root compromise confirmed and scope unclear

Recovery: - Rebuild from clean image if complete system compromise suspected - Restore from clean backups if rebuilding not feasible (scan backups first) - Re-enable accounts only after full security validation complete - Implement enhanced access controls (2FA, SSH keys only, IP whitelisting)

Infrastructure Failure Playbook

Scope: Server hardware failure, network connectivity loss, critical service failures (database, web server, email).

Failure Categories:

Failure Type	Detection Method	Primary Response
Hardware Failure	Hetzner notification, system unresponsive, hardware errors in logs	Escalate to Hetzner support immediately
Network Connectivity	Cannot connect to server, ping timeouts, Hetzner network status	Check Hetzner status page, open support ticket
Service Failure	Service down (Apache, MySQL, Exim), client reports	Restart service, investigate logs, check resources
Storage Failure	Disk errors in logs, read-only filesystem, I/O errors	Check disk health (`smartctl`), escalate to Hetzner if hardware
Resource Exhaustion	Out of memory, disk full, CPU maxed	Free resources, identify cause, scale if needed

Immediate Actions:

Assess Impact
How many clients affected?
Complete outage or degraded performance?
Critical services down (web, email, databases)?
Revenue/SLA impact?
Check Hetzner Status
Hetzner status page: status.hetzner.com
Datacenter-wide issue vs. specific server issue?
Scheduled maintenance forgotten?

Attempt Quick Recovery

# For service failures - attempt restart
systemctl restart httpd    # Apache web server
systemctl restart mysql    # MySQL database
systemctl restart exim     # Exim mail server

# For resource issues - free up space/memory
df -h                      # Check disk space
free -m                    # Check memory

Response Actions by Component:

Web Server (Apache/httpd) Failure: 1. Check error logs: /usr/local/apache/logs/error_log 2. Check resource usage: top (CPU/memory), df -h (disk space) 3. Test configuration: httpd -t or /scripts/rebuildhttpdconf 4. Restart service: systemctl restart httpd 5. If repeated failures: Investigate logs, check for DDoS or resource exhaustion

Database (MySQL) Failure: 1. Check error logs: /var/lib/mysql/*.err 2. Check for crashes: Look for crash recovery messages in logs 3. Verify disk space (MySQL requires space for temp tables) 4. Restart service: systemctl restart mysql 5. If corrupted tables: Run mysqlcheck --all-databases --auto-repair

Email (Exim) Failure: 1. Check mail queue: exim -bp (queue size) 2. Check logs: /var/log/exim_mainlog for errors 3. Check disk space (full disk prevents mail delivery) 4. Clear queue if necessary: Review and delete stuck messages 5. Restart service: systemctl restart exim

cPanel Service Failure: 1. Check cPanel status: /scripts/check_cpanel_rpms 2. Restart cPanel services: /scripts/restartsrv_cpsrvd 3. Check for updates needed: /scripts/upcp (cPanel update) 4. Review logs: /usr/local/cpanel/logs/error_log

Hetzner Escalation Procedure:

When infrastructure issues require Hetzner support:

Gather Information Before Escalation
Exact time issue started
Error messages from logs
Steps already taken to resolve
Server hostname and IP address
Create Support Ticket via Hetzner Robot (robot.hetzner.com)
Subject: Clear, specific description (e.g., "EU1 server hardware failure - unresponsive")
Priority: Critical/High based on severity
Details: Comprehensive information gathered above
Monitor Response
Hetzner SLA: Critical <1 hour, High <4 hours
Respond promptly to any Hetzner questions or requests
Keep incident log updated with Hetzner communications

Client Communication: - Notify all affected clients within 1 hour of outage start - Provide estimated time to resolution (if known) or regular updates - Use communication templates (see Communication Protocols)

Recovery: - Document root cause once identified - Implement preventative measures (monitoring, redundancy, etc.) - Update runbooks if new procedures discovered

Vendor/Supply Chain Incident Playbook

Scope: Security incidents affecting third-party vendors that impact MDHosting services (Hetzner datacenter issues, cPanel vulnerabilities, other service providers).

Common Vendor Incident Scenarios:

1. Hetzner Datacenter Incident - Power outage, network outage, hardware failures affecting multiple servers - DDoS attack on Hetzner infrastructure - Datacenter maintenance with unexpected impact

Response: - Monitor Hetzner status page (status.hetzner.com) for updates - Review Hetzner notifications in Robot panel - No direct action possible - vendor-dependent resolution - Focus on client communication and damage limitation

2. cPanel Security Vulnerability - Zero-day vulnerability announcement in cPanel/WHM - Security patch released requiring immediate update

Response: - Review cPanel security announcements (news.cpanel.com) - Assess vulnerability severity and exploitability - Apply security patches immediately if actively exploited: /scripts/upcp --force - If high-risk vulnerability: Consider temporary service restrictions until patched - Monitor logs for exploitation attempts

3. Software Supply Chain Compromise - WordPress core or popular plugin compromised - PHP/Linux package repository compromise

Response: - Assess scope (which clients use affected software?) - Communicate with affected clients immediately - Apply patches/updates as soon as available - If no patch available: Disable affected software or implement compensating controls

Vendor Incident Response Actions:

Vendor	Incident Type	Response Actions	Communication
Hetzner	Datacenter outage	• Monitor status page • Open support ticket if not acknowledged • Prepare client notifications	Notify clients within 1 hour
Hetzner	Security incident	• Follow Hetzner guidance • Implement recommended mitigations • Review affected services	Notify clients if data impact
cPanel	Vulnerability	• Apply security patches immediately • Review logs for exploitation • Assess client impact	Technical notice if client action required
cPanel	Service outage	• Monitor cPanel status • Apply updates when available • Use CLI alternatives if possible	Notify if affects client access
Other Vendors	Varies	• Follow vendor guidance • Assess MDHosting impact • Implement mitigations	Case-by-case determination

Client Communication for Vendor Incidents:

Transparency: Acknowledge vendor incident and our dependence on vendor resolution
Regular Updates: Even if "no change", provide updates every 4-6 hours for critical vendor incidents
ETAs: Provide vendor's ETA if available, or indicate "vendor investigating, no ETA yet"
Alternatives: Suggest workarounds if possible (e.g., webmail if cPanel down)

Documentation: - Log all vendor incidents even if MDHosting takes no direct action - Track vendor response times and communication quality - Use for vendor performance reviews and redundancy planning

Recovery and Follow-Up: - Conduct internal review: Could we have reduced impact? - Consider redundancy/alternatives if vendor proves unreliable - Update vendor escalation procedures based on experience

Communication Protocols

Effective communication during and after security incidents is critical for maintaining trust, meeting regulatory obligations, and ensuring coordinated response efforts.

Communication Principles

Timeliness: - Critical incidents: Client notification within 1 hour - High incidents: Client notification within 4 hours - GDPR breaches: ICO notification within 72 hours if high-risk - Vendor escalations: Immediate for critical infrastructure issues

Transparency: - Provide honest assessment of situation - Acknowledge what is known and unknown - Admit mistakes if MDHosting error caused incident - No speculation or promises that can't be kept

Consistency: - All communications reviewed by incident handler (Director) - Use approved templates for consistency - Maintain same messaging across all channels - Regular updates even if "no change" status

Clarity: - Plain English, avoid jargon - Explain technical issues in business terms - Clear action items for recipients - Contact details for questions

Communication Decision Matrix

Determine who to notify based on incident severity and type:

Incident Severity	Clients	ICO	Vendors	Legal Counsel	Law Enforcement
Critical	All affected immediately	If data breach (72h)	Hetzner/cPanel if infrastructure	If high-risk breach	If criminal activity
High	All affected within 4h	If data breach (72h)	As needed for resolution	If breach or legal issue	If unauthorized access
Medium	Affected if service impact	If data breach (72h)	As needed	Consult if uncertain	If evidence of crime
Low	Only if action required	If data breach (72h)	Routine channels	Rarely	Rarely

GDPR Breach Notifications: - All data breaches assessed per GDPR criteria - High-risk breaches: ICO notification mandatory within 72 hours - Data subject notification if high risk to rights and freedoms - See GDPR doc for complete procedures

Communication Templates

The following templates provide ready-to-use formats for common incident communications. Customise with specific incident details before sending.

Template 1: ICO Data Breach Notification

Purpose: Report high-risk personal data breach to Information Commissioner's Office within 72 hours Delivery: ICO online breach reporting tool (https://ico.org.uk/for-organisations/report-a-breach/)

Template Content:

Subject: Personal Data Breach Notification - MDHosting Ltd (ICO Ref: ZB044018)

Organisation Details:
- Organisation Name: MDHOSTING LTD
- ICO Registration: ZB044018
- Company Number: 09796097
- Contact Name: Matthew Dinsdale (Director)
- Contact Email: admin@mdhosting.co.uk
- Contact Phone: [Not applicable - contact via email]

Breach Details:
- Date/Time of Breach: [YYYY-MM-DD HH:MM]
- Date/Time Breach Discovered: [YYYY-MM-DD HH:MM]
- Nature of Breach: [Unauthorised access / Accidental disclosure / Loss of data / Other]
- Breach Description: [Detailed description of what happened, how it occurred]

Personal Data Affected:
- Categories of Data: [Names, emails, addresses, passwords, payment data, etc.]
- Number of Individuals Affected: [Approximate number]
- Special Category Data Involved: [Yes/No - specify if yes]
- Children's Data Involved: [Yes/No]

Consequences and Risk:
- Potential Consequences: [Identity theft, financial loss, privacy invasion, etc.]
- Risk Level to Individuals: [High/Medium/Low]
- Risk Assessment Rationale: [Why this risk level assigned]

Measures Taken:
- Containment Actions: [What we did to stop the breach]
- Notification to Individuals: [Yes/No/Planned - when]
- Mitigation Measures: [What we're doing to reduce harm]
- Preventative Measures: [How we'll prevent recurrence]

Technical and Organisational Measures:
- Existing Security: [Encryption, access controls, monitoring, etc.]
- Where Measures Failed: [What didn't prevent this breach]
- Improvements Implemented: [What we've added/changed]

Additional Information:
- Incident Reference: [INC-YYYY-MM-DD-###]
- Third Parties Involved: [Sub-processors, vendors if applicable]
- Law Enforcement Notified: [Yes/No]
- Further Information Available: [Contact details for follow-up]

Declaration:
This notification is submitted in compliance with UK GDPR Article 33.
We will provide further information as our investigation continues.

Submitted by: Matthew Dinsdale, Director
Date: [YYYY-MM-DD]

Template 2: Client Service Incident Notification

Purpose: Notify clients of service disruption or security incident affecting their hosting Delivery: Email to affected client(s)

Template Content:

Subject: [URGENT] Service Incident Notification - [Incident Type] - [Date]

Dear [Client Name],

We are writing to inform you of a [incident type] affecting your hosting service with MDHosting.

INCIDENT SUMMARY:
- Incident Type: [DDoS attack / Service outage / Infrastructure failure / etc.]
- Started: [YYYY-MM-DD HH:MM GMT]
- Status: [Ongoing / Contained / Resolved]
- Severity: [Critical / High / Medium]

SERVICES AFFECTED:
- [Your website(s): domain.com, domain2.com]
- [Email services: Yes/No]
- [Database access: Yes/No]
- [Control panel access: Yes/No]

IMPACT:
[Describe the impact - e.g., "Your website is currently unavailable" or "Email delivery is delayed"]

CAUSE:
[Brief explanation of what caused the incident]

ACTIONS TAKEN:
[List the steps we've taken to address the incident]
- [Action 1]
- [Action 2]
- [Action 3]

CURRENT STATUS:
[Detailed current status and what's happening now]

ESTIMATED RESOLUTION:
[Provide ETA if known, or "We are working to resolve this as quickly as possible and will provide updates every [X hours]"]

ACTIONS REQUIRED FROM YOU:
[None / Specific actions the client needs to take]

We sincerely apologise for this disruption to your service. We understand the impact this has on your business and are working diligently to resolve the issue.

UPDATES:
We will send updates [every X hours / when significant progress made]. You can also check status at [if applicable].

CONTACT:
If you have questions or concerns, please contact:
- Email: support@mdhosting.co.uk
- Support Portal: https://mdhosting.co.uk/billing
- Reference: [INC-YYYY-MM-DD-###]

Thank you for your patience and understanding.

Regards,
Matthew Dinsdale
Director, MDHosting Ltd

Template 3: Client Data Breach Notification

Purpose: Notify clients of personal data breach affecting their website visitors/customers Delivery: Email to affected client(s), followed by support ticket for tracking

Template Content:

Subject: URGENT: Data Breach Notification - Action Required

Dear [Client Name],

We are writing to inform you of a data breach that has affected personal data processed through your hosting account with MDHosting.

Under UK GDPR, we are required to notify you without undue delay as the data controller for your website.

BREACH DETAILS:
- Date/Time of Breach: [YYYY-MM-DD HH:MM]
- Discovery Date: [YYYY-MM-DD HH:MM]
- Nature of Breach: [Unauthorised access / Accidental disclosure / etc.]
- Affected Service: [Website / Email / Database]

WHAT HAPPENED:
[Clear explanation of how the breach occurred]

PERSONAL DATA AFFECTED:
- Data Categories: [Names, emails, addresses, passwords, etc.]
- Estimated Number of Individuals: [Approximate number of your customers/visitors]
- Source: [Contact form submissions / Customer database / User accounts / etc.]

MDHosting's IMMEDIATE ACTIONS:
[List actions we took to contain and remediate]
- [Action 1 with timestamp]
- [Action 2 with timestamp]
- [Action 3 with timestamp]

YOUR OBLIGATIONS AS DATA CONTROLLER:
As the data controller, you are responsible for:
1. Assessing the risk to your customers' rights and freedoms
2. Determining if ICO notification is required (72-hour deadline from awareness)
3. Determining if notification to affected individuals is required
4. Maintaining records of this breach in your breach register

We can assist you with understanding these obligations, but the decision and execution rest with you as the data controller.

RISK ASSESSMENT:
Our preliminary assessment: [High Risk / Low Risk]
Rationale: [Why we assessed this risk level]

Note: You must conduct your own assessment as the data controller.

INFORMATION WE CAN PROVIDE:
- Technical details of the breach
- Timeline of events
- Data categories and approximate numbers
- Containment and remediation measures
- Assistance with understanding GDPR obligations

ICO NOTIFICATION DEADLINE:
If you determine this is a high-risk breach, you must notify the ICO within 72 hours of becoming aware (i.e., by [YYYY-MM-DD HH:MM]).

ICO Contact: https://ico.org.uk/for-organisations/report-a-breach/ or 0303 123 1113

SUPPORT AVAILABLE:
We understand this is a serious matter. We are available to:
- Provide additional technical information
- Assist with your risk assessment
- Support your notification process
- Answer any questions

Please contact us immediately:
- Email: admin@mdhosting.co.uk
- Subject: Data Breach - [INC-YYYY-MM-DD-###]
- Urgent: Please respond within 24 hours

PREVENTING RECURRENCE:
We have implemented the following measures to prevent similar incidents:
[List preventative measures]

We sincerely apologise for this incident and are committed to supporting you through the response process.

Regards,
Matthew Dinsdale
Director, MDHosting Ltd

ICO Registration: ZB044018
Company Number: 09796097

---
This notification is provided in compliance with UK GDPR Article 33(2).
Incident Reference: [INC-YYYY-MM-DD-###]

Template 4: Vendor Escalation Request

Purpose: Escalate critical issues to vendors (Hetzner, cPanel, etc.) Delivery: Vendor's support ticket system

Template Content:

Subject: [URGENT/CRITICAL] [Issue Type] - [Server/Service Name] - MDHosting

Priority: [Critical / High]
Customer: MDHosting Ltd
Customer ID: [Customer/Account Number]
Affected Service: [Server hostname / License / Service]

ISSUE SUMMARY:
[One-line description of the problem]

IMPACT:
- Severity: [Complete outage / Service degradation / Security issue]
- Affected Customers: [Number of our clients impacted]
- Business Impact: [Revenue loss / SLA breach / Security risk]
- Duration: [Issue started at YYYY-MM-DD HH:MM - X hours ago]

DETAILED DESCRIPTION:
[Comprehensive description of the issue]

WHAT WE'VE OBSERVED:
- [Symptom 1]
- [Symptom 2]
- [Symptom 3]

TROUBLESHOOTING PERFORMED:
[List all troubleshooting steps we've already taken]
1. [Action taken] - Result: [Outcome]
2. [Action taken] - Result: [Outcome]
3. [Action taken] - Result: [Outcome]

ERROR MESSAGES:
[Paste relevant error messages or logs]

SYSTEM INFORMATION:
- Server/Service: [Hostname, IP, or service identifier]
- Operating System: [AlmaLinux 10.1 / etc.]
- Software Version: [cPanel version / etc.]
- Last Known Good State: [When it was working]
- Recent Changes: [Any changes before issue started]

SUSPECTED CAUSE:
[Our hypothesis about what might be wrong, if any]

REQUIRED RESOLUTION:
[What we need from vendor to resolve]

URGENCY JUSTIFICATION:
[Why this requires urgent/critical priority - impact on customers, security risk, etc.]

CONTACT INFORMATION:
- Primary Contact: Matthew Dinsdale
- Email: admin@mdhosting.co.uk
- Available: [24/7 for critical issues / Business hours]
- Preferred Contact Method: [Email / Ticket updates]

ADDITIONAL INFORMATION:
- Our Incident Reference: [INC-YYYY-MM-DD-###]
- Any related vendor ticket numbers: [If applicable]

Please provide:
1. Acknowledgement of this ticket with priority confirmation
2. Estimated time to resolution (ETA)
3. Regular updates (every [1-2 hours for critical, 4 hours for high])

Thank you for your urgent attention to this matter.

Matthew Dinsdale
Director, MDHosting Ltd

Communication Frequency

During Active Incidents: - Critical: Updates every 2 hours minimum (or when significant developments) - High: Updates every 4 hours minimum - Medium: Daily updates - Low: Updates when resolved or every 2-3 days

Post-Resolution: - Resolution notification sent immediately when incident closed - Post-incident summary within 7 days (for high/critical incidents) - Lessons learned communication (if relevant to clients)

Communication Channels

Client Notifications: - Primary: Email to registered account email - Secondary: Support ticket in Blesta portal - Critical incidents: Follow-up phone call if contact number available

ICO Notifications: - Online breach reporting tool (preferred): https://ico.org.uk/for-organisations/report-a-breach/ - Phone (urgent): 0303 123 1113

Vendor Escalations: - Hetzner: Support ticket via Robot panel (robot.hetzner.com) - cPanel: Support ticket via cPanel account portal - Emergency: Vendor phone support if available

Documentation of Communications

All incident communications must be documented: - Copy of all emails sent/received stored in incident folder - Ticket references and timestamps logged - Phone call notes documented with date, time, participants, summary - ICO notification confirmation saved - Vendor responses filed in incident documentation

Documentation Requirements

Comprehensive documentation is essential for compliance, forensic analysis, post-incident review, and continuous improvement. All security incidents must be properly documented throughout their lifecycle.

Incident Log Format

Incident Identifier:

Each incident must be assigned a unique identifier following this format:

INC-YYYY-MM-DD-###

Examples: - INC-2026-01-15-001 - First incident on 15 January 2026 - INC-2026-01-15-002 - Second incident on same day - INC-2026-02-03-001 - First incident on 3 February 2026

Incident Log Location: - Primary: /root/incidents/INC-YYYY-MM-DD-###/ - Backup: Stored in MDHosting documentation repository (sensitive details redacted)

Timeline Documentation

Every incident must maintain a detailed timeline documenting all actions, observations, and communications:

Timeline Template:

Date/Time (UTC)	Event/Action	Performed By	Notes
2026-01-15 14:23	Incident detected via [source]	M. Dinsdale	[Brief description]
2026-01-15 14:25	Initial assessment completed	M. Dinsdale	Severity: [level]
2026-01-15 14:30	Containment action: [description]	M. Dinsdale	[Result/outcome]
2026-01-15 15:00	Client notification sent	M. Dinsdale	Email to [client]

Timeline Requirements: - All timestamps in UTC for consistency - Include detection, assessment, containment, eradication, recovery actions - Document all communications (who, when, what) - Note all system changes or commands executed - Record any evidence collected

Evidence Collection and Preservation

Evidence Types: - System logs (authentication, firewall, application, web server) - Network traffic captures (if applicable) - File system snapshots or copies - Screenshots of suspicious activity - Email headers and message content - Database query logs

Storage Location:

/root/incidents/INC-YYYY-MM-DD-###/evidence/
├── logs/                 # System and application logs
├── screenshots/          # Visual evidence
├── network/              # Network captures (pcap files)
├── filesystem/           # File copies or snapshots
└── communications/       # Email, tickets, notifications

Evidence Handling: - Preserve original timestamps (use cp -p or rsync -a) - Create checksums (SHA-256) for integrity verification - Document chain of custody in evidence log - Restrict access to incident handler only (chmod 700) - Never modify original evidence (work on copies)

Retention Periods: - GDPR-related breaches: 3 years minimum (compliance requirement) - Security incidents (non-breach): 1 year minimum - Critical incidents: 2 years minimum - Forensic evidence: Until case resolution + 6 months

Breach Register

For incidents involving personal data breaches, maintain entries in the GDPR Breach Register as documented in GDPR Compliance Documentation (lines 1302-1378).

Breach Register Requirements: - Date and time of breach discovery - Nature of the breach and personal data affected - Number of data subjects affected - Likely consequences of the breach - Measures taken to address the breach - ICO notification details (if applicable) - Data subject notification details (if applicable)

Cross-Reference: All personal data breaches must be documented in both: 1. Incident log (this document) - technical response details 2. GDPR Breach Register - compliance and notification details

Post-Incident Report Template

A comprehensive post-incident report must be completed within 7 days of incident resolution for all High and Critical incidents. Medium and Low incidents require summary documentation.

Post-Incident Report Sections:

1. Executive Summary

Incident identifier and classification
Brief description (2-3 sentences)
Impact summary (affected systems, clients, data)
Resolution status and date

2. Incident Timeline

Detection date/time and method
Response actions chronology (from timeline documentation)
Resolution date/time
Total incident duration

3. Root Cause Analysis

Initial attack vector or failure point
Contributing factors
Why existing controls didn't prevent the incident
Technical details of the vulnerability or issue

4. Impact Assessment

Systems affected and downtime duration
Clients affected and service impact
Data affected (if any) and GDPR implications
Financial impact (if measurable)

5. Response Actions Taken

Containment measures and effectiveness
Eradication steps performed
Recovery procedures executed
Verification and testing completed

6. Lessons Learned

What worked well in the response
What could be improved
Gaps in detection or response capabilities
Training needs identified

7. Recommendations

Immediate actions required (implement within 7 days)
Short-term improvements (implement within 1 month)
Long-term strategic changes (implement within 3-6 months)
Responsible party and target completion dates

8. Appendices

Full incident timeline (detailed)
Evidence inventory
Communications log
System configuration snapshots
References to external documentation

Report Storage: - Primary: /root/incidents/INC-YYYY-MM-DD-###/post-incident-report.md - Secondary: MDHosting documentation repository (redacted version)

Report Distribution: - Director review: All High and Critical incidents - Quarterly review file: Summary of all incidents for trend analysis

Post-Incident Review Process

Post-incident reviews are critical for continuous improvement of security posture and incident response capabilities. Every incident provides learning opportunities that should be captured and acted upon.

Review Timeline

Immediate Post-Incident (24 hours after resolution): - Quick debrief: What happened, what worked, what didn't - Identify any immediate security gaps requiring urgent action - Document initial lessons learned

One Week Post-Incident: - Complete detailed post-incident report (High/Critical incidents) - Identify root causes and contributing factors - Develop action plan for improvements - Begin implementation of immediate recommendations

Two Weeks Post-Incident: - Review progress on immediate action items - Assess effectiveness of implemented changes - Update documentation and procedures as needed

One Month Post-Incident: - Final review of all action items - Verify all recommendations implemented or scheduled - Close incident formally in incident log - Archive incident documentation

Post-Incident Review Questions

Conduct a thorough review by answering these questions for each incident:

Detection Phase: - How was the incident first detected? - How long between incident occurrence and detection? (MTTD - Mean Time To Detect) - Could the incident have been detected earlier? How? - Did monitoring systems perform as expected? - What detection gaps were identified?

Response Phase: - How long between detection and initial response? (MTTA - Mean Time To Acknowledge) - Was the severity classification accurate? - Were the right people notified promptly? - Did communication protocols work effectively? - Were escalation procedures followed correctly?

Technical Response: - How long to contain the incident? (MTTC - Mean Time To Contain) - Were containment actions effective? - Did we have the right tools and access? - Was evidence properly preserved? - How long to fully resolve? (MTTR - Mean Time To Resolve)

Documentation and Compliance: - Was the incident properly documented throughout? - Were GDPR notification timelines met (if applicable)? - Were all required parties notified appropriately? - Is documentation complete and accurate?

Impact and Prevention: - What was the actual impact vs. potential impact? - Why did existing controls fail to prevent this incident? - What changes would prevent recurrence? - Are similar systems vulnerable to the same issue?

Lessons Learned Documentation

Format:

Each incident should produce a lessons learned document with these components:

What Happened: - Brief factual summary of the incident - Timeline of key events - Impact and scope

What Went Well: - Effective detection methods - Successful response actions - Helpful tools or procedures - Good communication examples

What Could Be Improved: - Detection delays or gaps - Response challenges encountered - Tool or access limitations - Communication breakdowns - Documentation issues

Specific Action Items:

Action Item	Priority	Responsible	Target Date	Status
[Description]	High/Medium/Low	M. Dinsdale	YYYY-MM-DD	Pending/In Progress/Complete

Example:

Action Item	Priority	Responsible	Target Date	Status
Implement automated backup verification	High	M. Dinsdale	2026-02-15	In Progress
Update firewall rules to block suspicious IPs	High	M. Dinsdale	2026-01-22	Complete
Deploy Wazuh SIEM for improved detection	Medium	M. Dinsdale	2026-03-31	Pending

Process Improvement

Continuous Improvement Cycle:

Identify gaps - From incident reviews and lessons learned
Prioritise improvements - Based on risk and feasibility
Implement changes - Update procedures, tools, or controls
Test changes - Verify improvements are effective
Document updates - Revise incident response procedures
Train on changes - Ensure awareness of new procedures

Documentation Updates:

After each significant incident, review and update: - This incident response document - Security monitoring procedures - GDPR compliance documentation - Client communication templates - Contact lists and escalation procedures

Quarterly Security Review

Every quarter, conduct a comprehensive review of all incidents:

Quarterly Review Agenda:

Incident Statistics:
Total incidents by severity level
Mean Time To Detect (MTTD) trends
Mean Time To Resolve (MTTR) trends
Incident categories breakdown
Trend Analysis:
Are certain incident types increasing?
Are response times improving?
Are the same issues recurring?
Are new threats emerging?
Action Item Review:
Status of all improvement actions from incidents
Effectiveness of completed improvements
Prioritisation of pending actions
Procedure Effectiveness:
Are incident response procedures being followed?
Do procedures need updating based on experience?
Are communication templates effective?
Capability Assessment:
Do we have adequate tools and access?
Are monitoring capabilities sufficient?
Is training up to date?
Are vendor relationships effective?
Strategic Planning:
Long-term security improvements needed
Resource allocation for next quarter
Integration of new systems (Wazuh, ApisCP)

Quarterly Review Output: - Summary report of quarter's incidents - Updated risk assessment - Prioritised action plan for next quarter - Budget recommendations for security improvements

Training and Preparedness

Effective incident response requires ongoing training, knowledge maintenance, and preparedness exercises. Regular practice and skill development ensure rapid and effective response when incidents occur.

Knowledge Requirements

The incident handler (Director) must maintain proficiency in the following areas:

Technical Skills: - Linux system administration (AlmaLinux, file systems, processes) - cPanel control panel administration - Networking fundamentals (TCP/IP, DNS, routing) - Log analysis and interpretation - Malware identification and removal - Database administration (MySQL/MariaDB) - Web server configuration (Apache, NGINX)

Security Skills: - Firewall management (CSF, iptables) - Intrusion detection and prevention - Forensic analysis and evidence preservation - Security monitoring and alerting - Vulnerability assessment - Threat intelligence and indicators of compromise

Compliance and Legal: - UK GDPR requirements and breach notification procedures - ICO reporting obligations and timelines - Data subject rights and obligations - Legal evidence handling and chain of custody

Soft Skills: - Crisis communication and client management - Decision-making under pressure - Documentation and report writing - Vendor escalation and coordination

Reference Resources

Internal Documentation: - Security Overview - Threat model and security architecture - GDPR Compliance - Data protection and breach procedures - Infrastructure Overview - System architecture - Contact List - Vendor and emergency contacts - Wazuh Deployment Plan - Future SIEM capabilities

External Resources:

UK GDPR and Compliance: - ICO Guidance: https://ico.org.uk/for-organisations/ - ICO Breach Reporting: https://ico.org.uk/for-organisations/report-a-breach/ - UK GDPR Full Text: https://www.legislation.gov.uk/uksi/2019/419/contents

Security Best Practices: - NIST Incident Response Guide: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf - SANS Incident Response Resources: https://www.sans.org/security-resources/ - OWASP Security Resources: https://owasp.org/

Technical Documentation: - cPanel Documentation: https://docs.cpanel.net/ - AlmaLinux Wiki: https://wiki.almalinux.org/ - Hetzner Docs: https://docs.hetzner.com/

Threat Intelligence: - UK NCSC Alerts: https://www.ncsc.gov.uk/section/keep-up-to-date/ncsc-alerts - CISA Cybersecurity Alerts: https://www.cisa.gov/news-events/cybersecurity-advisories

Incident Simulation and Exercises

Regular practice through tabletop exercises and simulations maintains readiness and identifies procedural gaps.

Quarterly Tabletop Exercises:

Conduct tabletop exercises every quarter (March, June, September, December) covering different incident scenarios:

Exercise Format: 1. Select incident scenario (rotate through types) 2. Walk through response procedures step-by-step 3. Identify required tools, commands, and contacts 4. Document gaps or challenges discovered 5. Update procedures based on findings

Scenario Rotation: - Q1: Data breach scenario (GDPR compliance focus) - Q2: Ransomware attack (containment and recovery) - Q3: DDoS attack (mitigation and client communication) - Q4: Unauthorized access (forensics and evidence preservation)

Exercise Documentation: - Date and scenario tested - Procedures followed correctly - Gaps or issues identified - Action items for improvement

Annual Full-Scale Drill:

Once per year, conduct a full-scale incident response drill: - Simulate actual incident from detection to resolution - Execute real commands in test environment (if possible) - Practice all communication templates - Time each phase of response (MTTD, MTTA, MTTC, MTTR) - Produce complete incident documentation - Conduct thorough post-incident review

Critical Tools Familiarity

Maintain hands-on familiarity with all tools required for incident response:

Security Tools: - Fail2Ban (ban management, log analysis) - CSF (ConfigServer Security & Firewall) - ClamAV and Maldet (malware scanning) - iptables (firewall rules) - tcpdump (network traffic capture)

System Tools: - ssh (secure access and remote management) - ps, top, htop (process monitoring) - netstat, ss (network connections) - journalctl, tail (log viewing) - find, grep (file and content search)

cPanel Tools: - WHM Security Center - Account management and suspension - Backup and restore functions - Log viewing and analysis

Forensic Tools: - sha256sum (file integrity verification) - rsync, cp -p (evidence preservation) - last, lastlog (login history) - history (command history review)

Practice Schedule: - Monthly: Review and test one category of tools - Quarterly: Full toolset review during tabletop exercise - Ad-hoc: Hands-on practice when new tools added

Staying Current

Monthly Activities: - Review NCSC and CISA security alerts - Read one incident response case study or post-mortem - Update knowledge of new threats and attack techniques - Review changes in UK GDPR guidance from ICO

Quarterly Activities: - Attend security webinar or online training - Review and update incident response procedures - Test incident simulation scenario - Assess new security tools or capabilities

Annual Activities: - Comprehensive security training course - Review full incident response framework - Update emergency contact information - Full-scale incident response drill

Integration with Future Systems

MDHosting is planning significant infrastructure improvements that will enhance incident response capabilities. These planned systems must be integrated into incident response procedures as they are deployed.

Wazuh SIEM Deployment

Planned Deployment: Q1 2025 (January-March)

Project Reference: Wazuh Deployment Plan

Impact on Incident Response:

Wazuh Security Information and Event Management (SIEM) will significantly enhance detection capabilities:

Detection Improvements: - Real-time security event correlation across all servers - Automated threat detection and alerting - File integrity monitoring (FIM) for critical system files - Vulnerability detection and reporting - Compliance monitoring (PCI-DSS, GDPR)

Integration Points:

Detection Phase:
Wazuh alerts become primary detection source
Automated severity classification based on rules
Reduced Mean Time To Detect (MTTD)
Initial Assessment:
Wazuh dashboard provides immediate incident context
Event correlation shows related activity
Automated evidence collection via Wazuh logs
Documentation:
Wazuh incident records supplement manual documentation
Alert exports provide timeline evidence
Compliance reports for GDPR breaches

Procedure Updates Required:

When Wazuh is deployed, update these sections: - Detection and Initial Assessment (add Wazuh as primary detection source) - Evidence Collection (include Wazuh alert exports and logs) - Metrics and Reporting (integrate Wazuh analytics) - Training (add Wazuh familiarity to required skills)

ApisCP Migration

Planned Migration: Q2-Q3 2025 (April-September)

Project Reference: ApisCP Migration Plan

Impact on Incident Response:

Migration from cPanel to ApisCP will change control panel procedures and tools:

Changes to Incident Procedures:

Tool References:
Replace cPanel/WHM commands with ApisCP equivalents
Update account suspension procedures
Revise backup/restore procedures
Update log file locations
Security Features:
ApisCP's enhanced security features (mod_security, Rampart)
Different firewall management (Rampart vs CSF)
New monitoring and alerting capabilities
Client Communication:
Update templates with ApisCP portal references
Revise client action instructions (password resets, etc.)

Procedure Updates Required:

During migration, create ApisCP-specific versions of: - Infrastructure Failure playbook (new control panel procedures) - Evidence Collection (ApisCP log locations) - Critical Tools Familiarity (ApisCP CLI tools) - Communication Templates (ApisCP portal references)

Migration Period Considerations:

During the migration (Q2-Q3 2025), maintain dual procedures: - EU1 server: cPanel procedures (until migrated) - Migrated servers: ApisCP procedures - Document which server uses which control panel in incident logs

Future Enhancements to Consider

Additional Security Monitoring: - Intrusion Prevention System (IPS) integration - Automated threat intelligence feeds - Cloud-based DDoS protection service

Automation Opportunities: - Automated incident ticket creation - Scripted containment actions for common incidents - Automated evidence collection workflows

As systems evolve, maintain this incident response documentation to reflect current capabilities and procedures.

Metrics and Reporting

Tracking incident metrics enables objective assessment of incident response effectiveness, identifies trends, and supports continuous improvement efforts.

Key Performance Indicators (KPIs)

Mean Time To Detect (MTTD): - Time between incident occurrence and detection - Target: <15 minutes for critical incidents, <1 hour for high incidents - Measurement: Timestamp of actual incident start vs. timestamp of detection - Improvement Actions: Enhanced monitoring, automated alerting (Wazuh deployment)

Mean Time To Acknowledge (MTTA): - Time between detection and beginning response actions - Target: <5 minutes for critical, <15 minutes for high, <1 hour for medium - Measurement: Timestamp of detection vs. timestamp of first response action - Improvement Actions: Automated alerting, mobile notifications, clear escalation

Mean Time To Contain (MTTC): - Time between detection and successful containment - Target: <1 hour for critical, <4 hours for high, <24 hours for medium - Measurement: Timestamp of detection vs. timestamp of containment completion - Improvement Actions: Automated containment scripts, better playbooks, practice

Mean Time To Resolve (MTTR): - Time between detection and full resolution (including verification) - Target: <4 hours for critical, <24 hours for high, <72 hours for medium - Measurement: Timestamp of detection vs. timestamp of incident closure - Improvement Actions: Improved recovery procedures, automated testing, better documentation

Additional Metrics:

Incident Volume: Total incidents per month/quarter by severity
Incident Categories: Breakdown by type (breach, malware, DDoS, etc.)
Recurrence Rate: Percentage of incidents that are repeats or related
False Positive Rate: Alerts investigated that weren't actual incidents
Compliance Rate: Percentage meeting response time targets
GDPR Compliance: Percentage of breaches reported to ICO within 72 hours

Monthly Incident Report

Report Frequency: First week of each month for previous month

Report Template:

# Security Incident Report - [Month Year]

## Summary Statistics

- Total Incidents: X
- By Severity: Critical (X), High (X), Medium (X), Low (X)
- By Category: Data Breach (X), Malware (X), DDoS (X), Unauthorized Access (X), Infrastructure (X), Vendor (X), Policy (X)

## Key Performance Indicators

| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| MTTD (Critical) | <15 min | X min | ✅/❌ |
| MTTA (Critical) | <5 min | X min | ✅/❌ |
| MTTC (Critical) | <1 hour | X hours | ✅/❌ |
| MTTR (Critical) | <4 hours | X hours | ✅/❌ |
| ICO Notification (72h) | 100% | X% | ✅/❌ |

## Significant Incidents

### [INC-YYYY-MM-DD-###] - [Brief Description]
- **Severity:** [Level]
- **Impact:** [Description]
- **Resolution:** [Summary]
- **Lessons Learned:** [Key takeaway]

[Repeat for each significant incident]

## Trend Analysis

- [Observation about incident patterns]
- [Changes from previous month]
- [Emerging threats or vulnerabilities]

## Action Items

| Action | Priority | Target Date | Status |
|--------|----------|-------------|--------|
| [Item from incident review] | High/Medium/Low | YYYY-MM-DD | Pending/Complete |

## Recommendations

- [Immediate actions needed]
- [Process improvements identified]
- [Tool or capability gaps]

Report Distribution: - Director review (primary incident handler) - Archived in /root/security-reports/monthly/ - Summary metrics tracked for quarterly review

Quarterly Security Review Integration

Quarterly Review Schedule: - Q1 Review: First week of April (covers Jan-Mar) - Q2 Review: First week of July (covers Apr-Jun) - Q3 Review: First week of October (covers Jul-Sep) - Q4 Review: First week of January (covers Oct-Dec)

Incident Response Component of Quarterly Review:

Include these incident-specific elements in the broader quarterly security review:

Aggregate Metrics:
Quarterly totals and averages for all KPIs
Trend lines showing improvement or degradation
Comparison to previous quarters
Pattern Analysis:
Recurring incident types or root causes
Seasonal trends (if any)
Attack vector evolution
Response Effectiveness:
Compliance with response time targets
Effectiveness of playbooks and procedures
Communication protocol performance
Capability Gaps:
Tools or skills needed
Detection blind spots identified
Process improvements required
Strategic Recommendations:
Budget allocation for security improvements
Training priorities for next quarter
System upgrades or deployments (Wazuh, ApisCP)

Output: Quarterly Security Review Report including incident metrics, trends, and strategic action plan for next quarter.

Annual Incident Summary

Report Frequency: January (covering previous calendar year)

Contents: - Full year incident statistics and trends - Year-over-year comparison - Major incident summaries and outcomes - Cumulative lessons learned - Annual improvement roadmap - Compliance summary (GDPR, ICO, response targets)

Purpose: Strategic planning, compliance documentation, board-level reporting

Appendices

Appendix A: Quick Reference - First 15 Minutes

Immediate Actions Checklist for ANY Incident:

0-2 minutes: Note current time (UTC), begin incident log, assign incident ID
0-2 minutes: Assess severity (Critical/High/Medium/Low) - determine response timeline
2-5 minutes: Contain immediate threat if obvious (isolate server, block IP, suspend account)
5-8 minutes: Preserve evidence (copy logs, take screenshots, document current state)
8-10 minutes: Determine if GDPR breach - flag for 72-hour ICO notification if yes
10-12 minutes: Notify affected clients (Critical: immediately, High: within 4h)
12-15 minutes: Begin detailed investigation, document timeline, escalate if needed

Remember: - Containment first, investigation second - Preserve evidence before making changes - Document everything in real-time - GDPR clock starts ticking immediately on breach detection

Appendix B: Emergency Contact Quick Reference

For full contact details, see Contact List

Contact	Use Case	Primary Method	Response Time
Hetzner Support	Infrastructure failures, DDoS, hardware issues	Support ticket (robot.hetzner.com)	<2h critical, <12h normal
cPanel Support	Control panel failures, software bugs	Support ticket (cPanel portal)	<4h priority, <24h normal
ICO	GDPR breach notification (high-risk only)	Online reporting tool	N/A (submit within 72h)
Action Fraud	Suspected criminal activity, fraud	Online: actionfraud.police.uk	N/A
Legal Counsel	Legal advice on serious breaches	Phone/Email	<4h for critical

ICO Breach Reporting: https://ico.org.uk/for-organisations/report-a-breach/

Action Fraud (UK): https://www.actionfraud.police.uk/ or 0300 123 2040

Appendix C: Log File Locations

System Logs:

/var/log/messages                 # General system messages
/var/log/secure                   # Authentication, SSH, sudo
/var/log/audit/audit.log          # SELinux audit trail
/var/log/dmesg                    # Boot and kernel messages

Web Server Logs:

/usr/local/apache/logs/error_log              # Apache errors
/usr/local/apache/domlogs/[domain]            # Per-domain access logs
/home/[username]/logs/                        # User-specific logs

Mail Logs:

/var/log/maillog                  # Mail server activity
/var/log/exim_mainlog             # Exim detailed log
/var/log/exim_rejectlog           # Rejected mail

Security Logs:

/var/log/fail2ban.log             # Fail2Ban bans and actions
/var/log/lfd.log                  # CSF Login Failure Daemon
/var/log/cphulkd.log              # cPanel brute force protection

Database Logs:

/var/lib/mysql/[hostname].err     # MySQL error log
/var/lib/mysql/slow-query.log     # Slow query log (if enabled)

cPanel/WHM Logs:

/usr/local/cpanel/logs/error_log  # cPanel errors
/usr/local/cpanel/logs/access_log # cPanel access
/usr/local/cpanel/logs/login_log  # cPanel login attempts

Appendix D: Useful Commands Reference

System Status:

uptime                            # System uptime and load
free -h                           # Memory usage
df -h                             # Disk space
systemctl status [service]        # Service status
journalctl -xe                    # Recent system logs

Network Diagnostics:

netstat -tulpn                    # Listening ports and connections
ss -tulpn                         # Socket statistics (modern alternative)
tcpdump -i any -n                 # Capture network traffic
ping [host]                       # Test connectivity
traceroute [host]                 # Trace network path

Security and Access:

last                              # Recent logins
lastlog                           # Last login for all users
w                                 # Currently logged in users
fail2ban-client status            # Fail2Ban status
fail2ban-client status [jail]     # Specific jail status
csf -d [IP]                       # Deny IP in CSF
csf -g [IP]                       # Search for IP in CSF

cPanel Specific:

/scripts/whoowns [domain]         # Find account for domain
whmapi1 suspendacct user=[user]   # Suspend account
whmapi1 unsuspendacct user=[user] # Unsuspend account
/scripts/restartsrv httpd         # Restart Apache
/scripts/restartsrv mysql         # Restart MySQL

Firewall (CSF):

csf -r                            # Restart CSF
csf -tf                           # Clear temporary bans
csf -a [IP]                       # Allow IP
csf -d [IP]                       # Deny IP
csf -g [IP]                       # Search for IP

Malware Scanning:

clamscan -r /home/[user]          # Scan user directory
maldet -a /home/[user]            # LMD scan user directory
maldet --report [scan-id]         # View malware scan report
maldet -q [file]                  # Quarantine specific file

Process Management:

ps aux | grep [process]           # Find process
kill -9 [PID]                     # Kill process
pkill -9 [process-name]           # Kill by name
lsof -i :[port]                   # Find process using port

Appendix E: Incident Severity Reference Card

Quick Severity Assessment:

Severity	Response Time	Examples	Notification
Critical	<1 hour	All servers down, active data breach, ransomware, root compromise	All affected clients immediately, ICO if breach
High	<4 hours	Single server down, malware outbreak, DDoS affecting service, unauthorized database access	All affected clients within 4h, ICO if breach
Medium	<24 hours	Service degradation, suspected compromise, non-critical vulnerability, malware on single account	Affected clients if service impact, ICO if breach
Low	<72 hours	Single account issue, failed login attempts, minor configuration error, policy violation	Notify only if client action required, ICO if breach

GDPR Breach Notification Reminder: - ICO notification required: Any breach likely to result in risk to individuals' rights and freedoms - Deadline: 72 hours from awareness of breach - Client notification required: If high risk to individuals - See: GDPR Compliance Documentation lines 1302-1378

Critical Decision Points: 1. Is this a GDPR breach? → Flag for 72-hour deadline 2. Are multiple systems affected? → Likely Critical severity 3. Is service completely unavailable? → Likely Critical/High severity 4. Is client data at risk? → Prioritise containment and notification 5. Do I need vendor support? → Escalate immediately for Critical/High

Document Control

Version History

Version	Date	Author	Changes
1.0	January 2026	M. Dinsdale	Initial comprehensive incident response procedures document

Review Schedule

This document must be reviewed and updated according to the following schedule:

Quarterly Review: - Frequency: Every 3 months (April, July, October, January) - Scope: Review all procedures, update metrics, assess effectiveness - Trigger: Scheduled quarterly security review - Owner: Director (M. Dinsdale)

Post-Incident Review: - Frequency: After any High or Critical incident - Scope: Update relevant playbooks, communication templates, procedures based on lessons learned - Trigger: Completion of post-incident report - Owner: Director (M. Dinsdale)

Annual Review: - Frequency: Annually in January - Scope: Comprehensive review of entire framework, strategic updates, compliance verification - Trigger: Annual security planning cycle - Owner: Director (M. Dinsdale)

Ad-Hoc Updates: - Trigger: Infrastructure changes (Wazuh deployment, ApisCP migration) - Trigger: Regulatory changes (UK GDPR updates, ICO guidance changes) - Trigger: Vendor changes (new providers, service changes) - Trigger: Organisational changes (new staff, role changes)

Next Scheduled Review

Next Review Date: April 2026 (Q1 2026 quarterly review)

This document is part of MDHosting's comprehensive security and compliance framework:

Core Security Documentation: - Security Overview - Security architecture and threat model - GDPR Compliance - Data protection and breach procedures (especially lines 1302-1378) - Security Monitoring - Monitoring systems and procedures (planned)

Infrastructure Documentation: - Infrastructure Overview - System architecture - Server Inventory - Detailed server specifications - Network Architecture - Network topology (planned)

Operational Procedures: - Backup and Recovery - Backup procedures (planned) - Server Maintenance - Maintenance procedures (planned)

Reference Materials: - Contact List - Emergency contacts and vendor information - Standards - Security standards and compliance (planned)

Project Plans: - Wazuh Deployment - SIEM implementation plan (planned) - ApisCP Migration - Control panel migration plan

Document Metadata

Document Status: Active

Classification: Internal - Confidential

Owner: Matthew Dinsdale, Director, MDHosting Ltd

Approval: Matthew Dinsdale, January 2026

Distribution: Internal use only - contains operational security procedures

Compliance Relevance: UK GDPR Article 33 (Breach Notification), ISO 27001 (Incident Management)

Last updated: January 2026 Next review: April 2026