Most arguments for ticket tools focus on operational efficiency: faster resolution, less context-switching, better team coordination. Those are real, but they're preferences. There's a separate argument that's not a preference — it's a compliance requirement. For any organisation under ISO 27001, NIS2, SOC 2, or sector-specific regulation (banking, healthcare, government), incident records in email are not adequate evidence. This piece is the audit case.
What auditors actually ask
An ISO 27001 surveillance audit on Annex A.5.24 (Information security incident management) doesn't ask "do you have a ticket tool?". It asks specific evidence questions:
- "Show me all security incidents reported in the last 12 months."
- "For incident #X, who detected it, when, and how was it categorised?"
- "What was the time from detection to containment? To resolution?"
- "Who approved the closure? On what evidence?"
- "Have there been recurring incidents of the same type? Are they linked to a Problem record?"
- "Which assets were affected? Which had GDPR-relevant personal data?"
NIS2 audit goes further — Article 23 mandates reporting "significant" incidents to the national CSIRT within 24 hours of detection, with a follow-up report at 72 hours and a final report at one month. Each of those reports must contain detection time, scope, impact assessment, and corrective actions.
What email cannot answer
Try answering the auditor's questions from email alone:
- "Show me all security incidents." Search Outlook for "incident", "security", "breach", "phishing"... You'll get marketing emails, false positives, and a partial list. Auditor: "How do you know it's complete?"
- "When was it detected?" Email timestamp = email received time. Detection time may have been earlier (someone noticed at 09:15, sent the email at 09:42 after talking to a colleague). Email gives the wrong number.
- "Who categorised it?" Categorisation in email is the body text, written by whoever wrote the email. There's no enforced taxonomy. Three different colleagues might write three different category names for the same kind of incident.
- "Time to resolution?" The "resolved" email might be in a different thread, forwarded between three people, with the actual resolution timestamp ambiguous.
- "Who approved closure?" "Yes, OK, close it" reply on a phone has no formal weight. DKIM-signed enterprise email is more trustworthy, but most replies don't preserve the chain integrity.
- "Recurring incidents linked to a Problem?" Email has no such structural concept. Auditor expects to see a Problem record with linked incidents — that's an explicit ITIL practice and explicit ISO Annex A.5.24 requirement.
What a ticket database answers in seconds
The same questions, with GLPI:
Q: All security incidents in last 12 months?
A: Filter Tickets, type=Incident, category=Security, date>now-12m
→ Export CSV. Done.
Q: For incident #1234, detection time, category, closure approval?
A: Open ticket. All four data points visible in detail view.
Audit log shows every state change with timestamp + user.
Q: Time to detection? Time to containment? Time to resolution?
A: Built-in MTTD/MTTR/MTBF report.
Q: Recurring incidents linked to a Problem?
A: Problems module → tabular view of Problem #X with all linked
Tickets. Auditor sees "yes, root cause identified, 14
incidents prevented since fix".
Q: GDPR-relevant assets affected?
A: Asset list filtered by custom field "Personal data: yes",
cross-referenced to incidents that touched those assets.The difference isn't aesthetic. It's the difference between "we have evidence" and "we'll need to ask around and reconstruct from memory". Auditors trust the first; the second triggers findings.
NIS2 24/72/1-month reporting
NIS2 Article 23 explicitly requires traceable, time-stamped records for incident reporting to the national CSIRT. The 24-hour early-warning report has to include "preliminary assessment of severity, impact, and indicators of compromise". The 72-hour incident notification adds technical details. The one-month final report has to demonstrate corrective actions and lessons learned.
Each of those reports references a single canonical incident ID. With email-based incident management, there is no canonical ID — what you submit at 24 hours, 72 hours, and one month may not align consistently. With a ticket database, ticket #1234 IS the canonical ID; all three reports are exports from the same record at three points in time. This isn't a "nice to have" — non-aligned reports are a compliance gap.
The bridge: ticket tools support, not replace, security tooling
To be clear: a ticket tool isn't a SIEM. It doesn't detect intrusions, correlate logs, or send alerts. The detection layer is monitoring (Wazuh, Splunk, Microsoft Sentinel). What the ticket tool does is the case-management layer above detection — once an alert becomes "this needs to be investigated and tracked", that record needs to live somewhere structured.
For organisations on the NIS2 path or working through ISO 27001 certification, the absence of structured incident records is a recurring finding. Adding a ticket tool to bridge SIEM → human → audit closes that gap with a single, well-defined system. Distinct from escalation mechanics and object-type semantics, which cover how the tool is operated; this piece is about why an auditor cares whether the tool exists at all.