A security incident is not a normal ticket. The requester pool is smaller, the assignee pool is smaller, and "the office manager just saw the phishing-investigation ticket pop up in the all-tickets view" is sometimes itself the incident. GLPI doesn't ship with a "classified" mode, but the existing entity, profile, category, and group features can be combined into something tight enough for ISO 27001 incident handling — provided you set it up before the first real incident, not during it.
Start with a private category
The biggest leak isn't an attacker — it's a curious agent browsing the queue. Open Setup > Dropdowns > ITIL categories and create a category for security incidents. On the category form, set Visible for tickets to Yes and add an explicit group of users in the Restricted to groups field. Only members of those groups will see the category in the dropdown when creating tickets, and only their tickets will surface for them in search.
You can take this further with sub-categories (e.g. Security > Phishing, Security > Data leak, Security > Account compromise) — each can scope to a different security sub-team if your org separates the SOC from infrastructure security.
Restrict the assignee profile
Categories control what gets created. Profiles control who can read after the fact. Create a profile called Security analyst and set See all tickets to No. The default Technician profile usually has this set to Yes — meaning every technician can list every ticket, regardless of category. That's the wrong default for security work.
Assign the Security analyst profile to the people who should investigate. They will see only tickets where they are requester, assignee, or watcher. Combine this with a business rule that auto-assigns any ticket with the security category to the security group, and the chain is closed: security tickets exist only in security people's queues.
Hide the solution from the requester
By default, the requester reads the entire solution field when a ticket is closed. For a security investigation, that's usually not what you want — you don't email the user "we determined this came from the marketing intern's compromised account." GLPI lets you mark individual followups as private: the followup is visible inside the ticket to assignees and watchers but is not sent to the requester and not visible on the self-service portal.
Train the analysts: investigation notes go in private followups. The solution field, which the requester does see, contains the user-facing version ("Confirmed phishing attempt. Recommended action: change password, enable MFA"). Two parallel narratives in the same ticket — internal and external.
Mute the notification engine on these tickets
Default notifications include the ticket title and the description body in the email. If a category is sensitive ("Security > Account compromise involving CFO"), that title lands in plain text in a mailbox somewhere — including, often, an Outlook search index. Edit the notification template for security categories: send the email with only a ticket number and a link. The recipient logs into GLPI to see the rest. Less convenient, much safer.
Use entities for the truly sensitive cases
Categories and profiles handle 95% of confidentiality. For the last 5% — board-level investigations, internal HR-IT incidents, suspected insider activity — create a dedicated entity. A separate entity in GLPI is its own scope: own categories, own users, own knowledge base, own search index. A user in the parent entity doesn't see anything in the sensitive child entity unless explicitly profiled in. It's heavier to maintain than categories, but for the cases where the existence of the ticket is itself confidential, it's the only structure that holds.
Audit who saw what
GLPI logs every ticket view in the Historical tab on the ticket itself. After a sensitive incident, that's the trail an auditor will ask for: which user, at which timestamp, opened this ticket. It's not turned into a regulatory-grade report out of the box, but the data is there. Export it before closing, attach to the post-incident review.