Answers are grounded in this paper and cite their sources.
Small organisations and educational institutions often record cyber incidents through emails, phone calls and spreadsheets, which scatters incident details, evidence references and response activities across different places. This paper presents the database design of the Cyber Incident Reporting and Response System (CIRRS), a MySQL relational database that organises incident information from reporting to investigation and resolution. The schema has seven tables: Users, Incidents, Affected_Systems, Evidence, Investigators, Incident_Actions and Resolutions. Primary keys and foreign keys connect the records, while SQL queries, joins and views support retrieval and reporting. The sample database holds 28 inserted rows, including four incidents and one resolution record. The tests show retrieval of related records, an updatable single-table view, a non-updatable aggregate view and the rejection of a delete that would violate referential integrity. The review also found a mismatch between incident status and resolution records: one incident has a resolution record but a status of Under Investigation, and another is marked Resolved without any resolution record. The paper focuses on database design and SQL behaviour, not on automated threat detection.
No takes yet. Share an insight, caveat, or question.
Johari et al. (2026) studied this question.
Synapse has enriched 10 related papers. Consider them for comparative context: