DSPT Standard: 6 — Responding to Incidents
Evidence: Incident log — 14 May 2026 (documented, tracked to resolution with verified corrective actions)
Incidents are detected through the following mechanisms:
| Source | Method | Frequency |
|---|---|---|
| Fail2ban | Automatically blocks brute-force and suspicious IPs; logs to /var/log/fail2ban.log |
Continuous |
| Trivy | Weekly container image vulnerability scan (Sunday 03:00) | Weekly |
| BorgBackup logs | Automated nightly backup success/failure logging | Daily |
| Watchtower | Docker container auto-update logging | Continuous |
| Manual checks | Daily quick checks (websites, backups, Fail2ban) and weekly deeper checks (disk, memory, firewall rules) via /security/dspt-monitoring-guide |
Daily + Weekly |
Any team member can also report an incident manually by contacting the Security Lead.
Specific step-by-step procedures for each scenario are documented in /security/dspt-operations-guide:
| Scenario | Procedure Location |
|---|---|
| Website down | /security/dspt-operations-guide (If the Website is Down) |
| Suspected security breach | /security/dspt-operations-guide (If You Suspect a Security Breach) |
| Backup failure | /security/dspt-operations-guide (If Backups Fail) |
| Fail2ban stopped | /security/dspt-operations-guide (If Fail2ban Stops Working) |
| Firewall off | /security/dspt-operations-guide (If the Firewall is Off) |
| Can't SSH in | /security/dspt-operations-guide (Can't SSH In) |
Detection → Triage → Containment → Investigation → Remediation → Verification → Closure
| Phase | Description | Owner |
|---|---|---|
| Detection | Automated alert or manual report | Any team member |
| Triage | Assess severity and impact | Security Lead |
| Containment | Isolate affected systems; stop further damage | Technical Lead |
| Investigation | Root cause analysis | Technical Lead |
| Remediation | Apply corrective actions | Technical Lead |
| Verification | Confirm fix is effective | Security Lead |
| Closure | Finalise incident log; document lessons learned | Security Lead |
All incidents are recorded in /infrastructure/security/incidents/ with the following fields:
| Field | Required |
|---|---|
| Incident ID | Yes |
| Date/Time Detected | Yes |
| Source | Yes |
| Severity | Yes |
| Description | Yes |
| Affected Systems | Yes |
| Actions Taken | Yes |
| Resolution Status | Yes |
| Corrective Actions | Yes |
| Verified By | Yes |
| Verification Date | Yes |
| Role | Responsibility |
|---|---|
| Security Lead | Declares incident, coordinates response, verifies corrective actions, communicates with stakeholders |
| Technical Lead | System recovery, backup restoration, infrastructure assessment, root cause analysis |
Both roles are held by the two directors. The Operations Guide (/security/dspt-operations-guide) and Monitoring Guide (/security/dspt-monitoring-guide) provide the detailed procedures for response.
The full incident report is at /infrastructure/security/incidents/incident-report-14-may-2026 with findings and recommendations at /infrastructure/security/incidents/incident-report-14-may-2026/findings-and-recommendations.
| Evidence | Location |
|---|---|
| Incident log | /infrastructure/security/incidents/ |
| 14 May 2026 incident report | /infrastructure/security/incidents/incident-report-14-may-2026 |
| Response procedures | /security/dspt-operations-guide |
| Monitoring procedures | /security/dspt-monitoring-guide |
| Incident response policy | This page (/policies/standard_6b_incident-response) |