Incident Response Module

The Incident Response Module provides a complete system for managing security, compliance, and operational incidents throughout their entire lifecycle. Unlike traditional logging systems, this module integrates structured root cause analysis, impact assessment, stakeholder management, and SLA enforcement into a unified workflow.

Supported Incident Types

Type	Description	SLA Priority
Cybersecurity	Security breaches, malware, unauthorized access	Highest
Fraud	Financial fraud, embezzlement, forgery	High
Safety	Workplace accidents, environmental hazards	Highest
Compliance	Regulatory violations, policy breaches	High
Privacy	Data breaches, PII exposure	High
ESG	Environmental/social incidents	Medium
Operational	Service disruptions, process failures	Medium
Reputational	PR crises, brand damage	High

Permissions

Permission	Description
incident_view	View incidents and register
incident_create	Report new incidents
incident_edit	Edit incident details
incident_delete	Delete incidents
incident_rca	Perform root cause analysis
incident_treatments	Manage treatment actions
incident_close	Close incidents
incident_impact	Assess and record impacts
incident_stakeholders	Manage stakeholder notifications
incident_sla_manage	Configure SLA rules

Each incident moves through a defined lifecycle with distinct statuses:

1. Detected — Incident has been identified and logged
2. Triaged — Initial assessment completed, priority determined
3. Investigating — Active investigation and data collection underway
4. Contained — Immediate impact contained, further damage prevented
5. Eradicated — Root cause removed, systems cleaned
6. Recovered — Normal operations restored
7. Closed — All actions complete, incident formally closed

Status transitions are recorded in the Activity Timeline with timestamps for each stage.

Accessible at /incidents/dashboard.php, the incident dashboard provides:

• Stats Cards — Total incidents, open incidents, critical open, SLA breaches
• By-Type Breakdown — Open incidents grouped by type (cybersecurity, fraud, etc.)
• By-Severity Breakdown — Open incidents grouped by severity (critical, high, medium, low)
• Recent Incidents — Last 15 incidents with filters for type and severity

Accessible at /incidents/register.php, the register provides a paginated, filterable list of all incidents:

• Filter by type, severity, status, department, assignee
• Free-text search across title and description
• Sortable columns with status badges and severity indicators
• Quick actions to view, edit, or close each incident

Accessible at /incidents/create.php. The intake form auto-generates a unique incident reference number in the format INC-YYYY-NNNN.

Required Fields

• Title — Brief, descriptive incident name
• Incident Type — One of: cybersecurity, fraud, safety, compliance, privacy, ESG, operational, reputational
• Severity — Critical, high, medium, or low
• Description — Detailed account of what happened

Optional Fields

• Department — Affected department (from organization structure)
• Assigned To — Primary incident responder
• Detected At — When the incident was first detected

The RCA module offers four analysis methods. Choose from the method buttons in the incident view: 5-Why (sequential questioning with color-coded cards), Fishbone/Ishikawa (6M cause-and-effect with interactive canvas diagram), Fault Tree (AND/OR gate logic with hierarchical tree builder), and Causal Loop (feedback polarity with curved arc connections). Each method flags failed controls that reduce their effectiveness scores and feed into the compliance module.

1. Why #1 — What is the direct cause of the incident?
2. Why #2 — What caused the level 1 cause?
3. Why #3 — What caused the level 2 cause?
4. Why #4 — What caused the level 3 cause?
5. Why #5 — What is the fundamental systemic cause?
6. Root Cause Summary — Concise statement of the underlying cause

Each level includes placeholder examples to guide the analyst. The wizard enforces sequential completion and provides visual feedback with color-coded cards.

Control Failure Flagging

During RCA, analysts can flag controls that failed or contributed to the incident. Selected controls automatically have their effectiveness_score reduced by 1 point (minimum 1), and the change is recorded in the control flags table and activity log.

Accessible at /incidents/impact.php?id=X. Record and track impacts across multiple categories:

Category	Description	Monetary
Financial	Direct financial losses, costs, fines	Yes
Operational	Service disruption, productivity loss	Optional
Reputational	Brand damage, customer trust	No
Regulatory	Compliance violations, legal exposure	Yes
Safety	Physical harm, workplace safety	No
Environmental	Environmental damage, spills	Optional

Each impact can include a description, estimated amount (with currency), and impact score.

Accessible at /incidents/stakeholders.php?id=X. Manage stakeholder notification records:

Type	Examples	Channel
Regulator	DPA, SEC, Central Bank	Portal, Email
Board	Board of Directors, Audit Committee	Email, In-person
Customer	Affected clients, partners	Email, Phone
Internal	Staff, management	Email, In-person
Insurance	Cyber insurance, liability carriers	Portal, Letter
Legal	Legal counsel, external attorneys	Email, Phone

Track when each stakeholder was notified, their response, and the notification channel used.

Accessible at /incidents/treatments.php?id=X. Define and manage corrective, preventive, and compensating actions:

Action Types

• Corrective — Fixes the immediate problem
• Preventive — Prevents recurrence
• Compensating — Alternative control until permanent fix

Workflow

Treatments follow a status workflow: Open → In Progress → Verified → Closed. Each treatment can be assigned to a user with a due date, and verification requires a second user to confirm completion.

SLA rules are configured per incident type and severity combination. Default rules are seeded during setup and include:

Type	Severity	Response (hrs)	Containment (hrs)	Resolution (hrs)	Escalation (hrs)
Cybersecurity	Critical	1	4	24	2
Cybersecurity	High	4	8	48	6
Fraud	Critical	2	8	48	4
Safety	Critical	1	2	24	1
Compliance	Critical	2	8	48	4
Privacy	Critical	1	4	24	2

The cron/check_incident_slas.php script runs periodically and automatically:

• Flags incidents exceeding response/containment/resolution thresholds as SLA breaches
• Creates activity log entries for each breach
• Sends notifications to assigned users and administrators
• Triggers escalation notifications when escalation thresholds are exceeded

Accessible at /incidents/close.php?id=X. The closure process includes:

1. Checklist — Verify RCA completed, treatments resolved, impact reviewed, stakeholders notified, evidence complete
2. Final Status — Choose "Closed" or "Recovered"
3. Closure Notes — Summary of actions taken and outcomes
4. Lessons Learned — What went well and what should change

Automatic Integrations on Close

• Compliance Flagging — Incidents of type compliance, privacy, fraud, or cybersecurity automatically generate compliance alerts and notifications to administrators
• Risk Event Creation — ALL incidents create risk entries in the risk register. Critical/high get 30-day review cycles with higher scores. Medium/low get 90-day cycles. Each risk entry auto-generates a mitigation control in the Control Library linked back to the original incident for tracking.

The Incident Response module integrates with:

IMS Investigations

Link incidents to IMS investigations for deeper forensic analysis. Accessible at /incidents/link_ims.php?incident_id=X. Creates an IMS case pre-populated with incident details and records the link in the activity timeline.

Control Library

RCA control failure flagging automatically updates control effectiveness scores and creates control flag records visible in the incident view.

Risk Register

Critical and high-severity incidents generate risk events on closure, linking incident management to the broader risk management framework.

Notifications

SLA breaches, compliance alerts, and escalations generate in-app notifications for affected users.

The Incident Response API is available at /api/incidents.php:

Method	Endpoint	Description
GET	/api/incidents.php	List all incidents
GET	/api/incidents.php?id=X	Get single incident with related data
POST	/api/incidents.php	Create new incident (JSON body)
PUT	/api/incidents.php?id=X	Update incident fields
DELETE	/api/incidents.php?id=X	Delete incident

The SLA check can be triggered via /api/incident_sla_check.php?trigger=1 (requires incident_sla_manage permission).