GLPI for ISO 27001 incident and change records

How GLPI records support ISO 27001 incident and change management

GLPI can produce much of the evidence an auditor asks for on incidents and changes, but it cannot make your ISMS compliant on its own. ISO/IEC 27001 certification is issued by accredited certification bodies after an audit, never by GLPI or DeployOpen, and ISO itself does not certify organizations. Annex A of ISO/IEC 27001:2022 lists 93 controls in four themes. This page focuses on the organizational and technological controls that touch incident handling and change control, such as the controls on information security incident management, change management and logging. Policy, risk assessment, management review, competence and the decision on what counts as a significant incident remain outside the platform and need documents and governance from your team.

On the GLPI side, the evidence sits in tickets, problem records, change records with their approval steps, and history logs. GLPI 11.0 added business rules for changes and problems, group approval requests, and approvals grouped by validation step, so the approver of each step can be shown alongside the timestamp. Before you rely on these records, confirm with your auditor which fields they expect to see, and set your history log retention per entry type. Teclib advises purging logs rather than keeping everything, so the retention period should be a documented decision that matches your own logging control and any privacy obligations, not a default you inherit.

Plan two gaps early. First, GLPI records what your team entered, so emergency changes, unrecorded hotfixes and incidents handled by phone need a rule that forces a ticket or change record. Second, the history log shows who changed a field, but it does not replace access control on the platform itself. Confirm how administrator actions and the ability to edit closed records are restricted, and check that your audit trail and backups follow the same retention rules. Ask your certification body which evidence it samples in an ISMS audit, then test a sample of closed incidents and changes against those criteria before the audit begins.

Mapping ISO 27001 Annex A incident and change requirements to GLPI features

This table maps the Annex A controls for incident handling and change management to the GLPI records that can hold their evidence, and to the settings each one needs. Approval, business rule and survey capabilities for changes and problems come from the GLPI 11.0 changelog, so confirm them in your target version before designing around them. The main takeaway is that GLPI holds the records, while your policy sets the triage criteria, approval design and retention periods.

Annex A requirement	GLPI capability	Configuration needed
A.5.24 Incident management planning and preparation: defined roles, categories and escalation paths	Ticket categories, SLAs and escalation, routing rules to assigned groups	Security incident categories, a named response group, escalation levels and SLA values set by your policy
A.5.25 Assessment and decision on events: triage and classification of each event	Ticket priority, urgency and impact fields, with history of changes to them	Priority matrix agreed with security, mandatory category and impact fields on security tickets
A.5.26 Response to incidents: actions taken and who took them	Ticket followups, tasks, assignee history and links to problems and changes	Require tasks for containment steps and confirm which actions the history log records in your version
A.5.27 Learning from incidents: root cause and lasting fixes	Problem records linked to tickets, with problem business rules added in GLPI 11.0	Business rules requiring root cause and fix fields before a problem can close, confirmed in your version
A.5.28 Collection of evidence: complete records retained for a defined period	History logs for item changes, with retention configurable per entry type	Retention per entry type matched to your evidence period, since Teclib advises purging logs rather than keeping everything
A.8.32 Change management: changes authorized before implementation	Change records, business rules for changes and approvals grouped by validation step (GLPI 11.0)	Change types, approval groups, validation steps and rules that block closure without approval
A.8.32 Change management: review of change outcomes	Satisfaction surveys for changes (GLPI 11.0) and problem records for failed changes	Enable change surveys and link failed changes to problems; survey results do not replace a formal review

Configuring GLPI for incident records versus change records

GLPI's ticket model holds incident and service request records, and problem records link recurring incidents to a root cause investigation. For traceability, the settings that matter most are ticket categories, the status workflow, assignment to a user or group, and the SLA or OLA clock. GLPI writes changes to these fields to the history log, which is the evidence an auditor uses to show when an incident was classified, reassigned or closed. The GLPI 12 data and privacy documentation notes that history retention is configurable per entry type and that Teclib advises purging logs on a schedule, so retention must be set with audit and privacy needs in view.

Category taxonomy: Define incident and service request categories that match your classification scheme, so reports can separate security incidents from operational ones.
Status and closure rules: Decide which statuses are final and who may close a ticket, so closed records always carry a resolution and an identifiable closing actor.
Assignment: Assign each ticket to a group as well as a technician, so unowned work appears in queue reports instead of disappearing into a personal queue.
Problem linkage: Link incidents to a problem record for root cause analysis, and record the workaround and known error decision on the problem itself.
Log retention: Confirm which entry types are logged in your version and set a purge period per type that matches your audit and data protection obligations.

Check the exact ticket and problem fields, status names and retention options in your installed version before you write a configuration standard.

Evidence GLPI produces for auditors and how to keep it

An auditor testing incident and change controls samples records, then checks that the history behind them still exists. The items below are the GLPI records most often sampled, and each one depends on retention settings that your own policy should decide, not the defaults.

Ticket and problem records

Incident tickets show what was reported, when it was acknowledged, who worked it and how it was closed. Problem records link recurring incidents to a root cause and a known error. An auditor typically samples a set of tickets across a period and checks that categories, priorities, timestamps and closure notes are complete. Confirm that closure requires a resolution entry and that problems link back to the incidents that triggered them.

Change records with approval history

A change record should show the request, the risk assessment, the approver and the implementation outcome. The auditor compares the approval timestamp with the implementation timestamp to confirm approval came first. Since GLPI 11.0, business rules for changes and problems are available, so approval routing can be configured rather than handled by convention. Confirm the rules your change policy requires are the ones that are active in production.

Approval steps grouped by validation step

GLPI 11.0 groups approvals by validation step and supports group approval requests. This matters when a change needs both a technical reviewer and a business owner, because the auditor will ask who approved which stage. Test a sample change end to end and confirm that each step records its own approver, decision and date. Document who may act for a group when a member is absent.

Satisfaction surveys for changes

GLPI 11.0 adds satisfaction surveys for changes. These records show how requesters and affected teams rated the outcome. They are useful as evidence that post-change review happens, but they are not a substitute for a documented review of failed or backed-out changes. Decide which change types require a survey and which require a written post-implementation review, and check that the survey responses are retained with the change.

History logs and their retention

History logs record field-level changes to tickets, problems and changes, including who changed what and when. They are often the strongest evidence that a record was not altered after approval. Teclib advises purging logs rather than keeping everything, so retention needs a deliberate setting. Configure retention per entry type to match your organization's own policy, check the setting after each upgrade, and document the period in your records management procedure so the auditor sees policy and practice agree.

Configuration sequence for an ISO 27001-ready record trail

This sequence turns GLPI from a general ticketing tool into a record trail that can be explained to an ISMS owner and an auditor. Each step fixes one design decision before the next depends on it, so the incident and change records you produce can be traced to an agreed process, approvers and retained history.

Define the incident and change process with the ISMS owner
Before any GLPI configuration, the ISMS owner, the IT service manager and the security lead agree on what counts as an incident, what counts as a change, which changes need approval, and who may approve them. Write this down as a short process document that names the stages, the roles and the records each stage must leave behind. Record the agreed document version so later configuration can be traced back to it. Done when the owner signs off the process and every stage has a named record type in GLPI.
Configure categories, statuses and urgency values
Map the agreed process onto GLPI ticket categories, change and problem types, and status values so that each record can be classified consistently. Keep the category list short enough that technicians choose the same value for the same kind of event, and remove default values that do not match your process. Test a sample of each type and confirm that the status lifecycle matches the process document. Done when a test record of each type moves through every status the process defines.
Set up approval groups and validation steps
Create the groups that approve changes and assign them to validation steps, following the approval routing the process describes. The GLPI 11.0.0 changelog added business rules for changes and problems, group approval requests and approvals grouped by validation step, so confirm these options exist in your installed version before you design around them. Check that a change cannot reach an implementation status without the required approvals. Done when a test change requiring two approvals is blocked until both approvers respond, and the approval history shows who approved and when.
Define business rules for incidents, problems and changes
Write the business rules that set defaults, mandatory fields and routing for incidents, problems and changes, so that required information such as affected asset, risk notes or back-out plan is captured at creation rather than added later. Review each rule against the process document and record its purpose in a rules register kept with the configuration. Ask your GLPI partner or the GLPI documentation for the rule options available in your version before drafting them. Done when each rule has an owner, a stated purpose and a test record showing it fires as written.
Set history log retention per entry type
GLPI keeps history log entries, and retention is configurable per entry type. Decide how long each type of history must be kept based on the ISMS owner's retention requirements and any legal obligations that apply to your data, then configure purge periods to match. Teclib advises purging logs rather than keeping everything, so retention should be a deliberate decision and not a default left in place. Document the chosen periods and the reason for each. Done when the retention settings are written in the register and a scheduled purge is confirmed to run as configured.
Restrict who can edit or delete records
Use GLPI profiles and entity rights to separate who can create, assign, approve and close records from who can edit or delete them. Remove delete rights from general technicians for tickets, changes and problems, and limit administrative access to a small named group. Confirm that approvers cannot alter the change content they approve, or that such edits are visible in history. Done when a test user with each profile is checked against a matrix of allowed actions and the results match the access model the ISMS owner signed off.
Protect configuration and encryption keys through installs and updates
Installation and update work can change record integrity, so include it in the plan from the start. The GLPI update procedure requires a backup of the database, the files and the config directory, including glpi.key and glpicrypt.key, before application files are replaced and php bin/console db:update is run. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so confirm that approval and business rule plugins are working after each upgrade. Store the key files separately from the backups in a controlled location, and test a restore to a non-production copy. Done when a restore test reproduces a sample ticket, change and its history with the keys intact.
Run a sample review of the record trail
Select a sample of closed incidents and completed changes and trace each one from creation through classification, approval, implementation and closure, checking the history log at every step. Compare what you find against the process document and the access model, and log every gap with an owner and a fix. Repeat the review after each configuration change and after each GLPI upgrade. Done when the sample shows a complete, attributable trail for each record and the gap log is closed or accepted by the ISMS owner. Note that DeployOpen prepares records and evidence for assessment; certification decisions rest with an accredited certification body.

What GLPI records do not cover for ISO 27001

GLPI tickets, problem records, change approvals and history logs show what happened in IT service management. They do not decide what risks matter, what the ISMS covers, or whether an event is a security incident. The cards below mark where those responsibilities sit outside the platform and what to confirm before an audit.

Risk assessment stays outside GLPI

GLPI can hold risk-related tickets and linked assets, but it does not perform the risk assessment that ISO/IEC 27001 clause 6.1.2 requires. The risk criteria, likelihood and impact scales, and risk treatment decisions live in your ISMS documents. Check that each change or incident record can be traced to a risk register entry maintained by your team, and confirm with Teclib which risk-related fields, if any, GLPI ships with in your version.

ISMS scope and policies are not in GLPI

GLPI can record categories, business rules and approval groups, but it does not define the ISMS scope, the information security policy or the topic-specific policies that govern incident and change handling. Auditors will compare GLPI workflows against documents approved by management. Keep the policy set in your document system, then map each GLPI business rule to the policy clause it implements.

Code and deployment evidence sits elsewhere

A GLPI change record shows that a change was requested and approved, but it usually does not prove what code or configuration was deployed. Source control, CI/CD pipelines and deployment logs hold that evidence. Confirm which system is the authoritative source for each production change, and link GLPI change IDs to commit or pipeline references so an auditor can follow one change across both systems.

Incident classification needs a defined rule

GLPI ticket categories and priorities do not decide whether an event is a security incident, a privacy breach or a routine service fault. That decision depends on criteria your organization defines and applies consistently. Write the classification criteria and the escalation path to the security team, then check that ticket templates or categories reflect them, and that reclassifications are recorded in the ticket history.

Certification comes from a certification body

GLPI records can support an internal audit or a certification body's sampling, but neither the platform nor DeployOpen issues an ISO/IEC 27001 certificate. Only an accredited certification body can do that, and it audits the whole management system, not the tool. Ask the certification body which records it will sample and in what format, and confirm the evidence period it expects before the audit starts.

Process discipline depends on people

A workflow in GLPI only produces reliable evidence if technicians open tickets, record approvals and close changes within the defined process. The platform cannot force a team to skip a ticket for an urgent fix or to record a verbal approval afterward. Measure how often changes bypass GLPI, review those exceptions at management review, and confirm with Teclib which settings can require fields or block closure in your version.

What certification auditors ask for from incident and change records

Certification to ISO/IEC 27001 is not granted by ISO. An accredited certification body performs the audit, and it works to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, the version that IAF MD 29:2024 required certification bodies to apply to all clients by 31 March 2026. Under ISO/IEC 17021-1, a management system certification cycle lasts three years, and the certification body must carry out at least one audit, either surveillance or recertification, in every calendar year of that cycle. For incident and change management, this means your GLPI records are not reviewed once. They are sampled during each audit, so the process has to produce a steady flow of closed tickets, approved changes and reviewed problems across the whole cycle. The transition to the 2022 edition also matters for planning. IAF MD 26:2023 required all certifications to ISO/IEC 27001:2013 to expire or be withdrawn by 31 October 2025, so an organization still carrying an older certificate needs to confirm its current status with its certification body and the IAF CertSearch database.

Auditors typically select a sample of incidents and changes from the period under review and trace each one. For a sampled incident, they will expect to see a ticket with a clear category, timestamps for logging and resolution, the assigned group, the actions taken, and evidence that the record was closed by someone other than the person who did the work where your procedure requires it. For a sampled change, they will look at the request, the risk assessment, the approval step and approver, the implementation window and the closure notes. Confirm with your certification body how many records it expects to sample and which period it will cover, because those choices determine how much history your GLPI instance must keep. Also confirm how the history log retention settings you choose in GLPI will affect what remains available during a surveillance audit.

DeployOpen prepares the records, configuration and written controls that these audits examine, including workflow design, approval routing, retention settings and sample evidence exports. DeployOpen does not audit your ISMS, issue an attestation or certify the result. That judgment belongs to your independent certification body, and the role of your own internal audit is to test the same evidence before the external auditor does. Agree in writing, before the build starts, which artifacts are delivered, which tests are run against them and who signs off on each one.

Questions teams ask before configuring GLPI for ISO 27001

Does GLPI alone satisfy ISO 27001 incident and change management controls?

No. GLPI supports these controls by recording tickets, problem records, change requests, approvals and history logs, but it does not make a process compliant on its own. The Annex A controls for incident management and change management are about how your organization defines, runs and reviews those processes. GLPI gives you a place to record the evidence, and your ISMS defines the rules the records must follow. Certification decisions are made by an accredited certification body, not by the software vendor or by DeployOpen. In GLPI 11.0.0, business rules for changes and problems, group approval requests and approvals grouped by validation step were added, which help enforce the process you document.

What configuration effort should we expect, and what drives it?

Effort depends mostly on how many process paths you have and how much of the workflow you want the tool to enforce. The main drivers are the number of ticket categories and change types, how approval chains map to your existing change advisory board, how many groups and entities need separate routing, and whether you must integrate with monitoring or identity systems. Plan for a process design phase before any configuration, followed by testing with real records. Ask any implementation partner to break the work into design, configuration, testing and handover, and to state which items are fixed in the written scope.

Can our own IT team configure this internally?

Often yes, if the team already administers GLPI and has someone who understands your change and incident process well enough to write it down. The harder part is usually not the clicks in the interface but agreeing on the rules: who approves what, what counts as a major incident, and which records must exist before a change closes. A team with that knowledge and time can build it internally. Teams without GLPI administration experience, or those that need an independent review of their design before an assessment, often bring in a partner for part of the work. Decide which parts you keep and which you outsource before requesting a quote.

What do the ISMS owner and IT each need to provide?

The ISMS owner should supply the documented incident and change procedures, the risk criteria that decide change categories, the roles that approve changes, and the evidence the auditor will ask for. IT should supply the current ticket and change practice, the list of systems in scope, the notification channels, and access to a test instance. Both need to agree who signs off the final workflow, because a configuration that does not match the written procedure creates a finding even when the software works. Name these owners in the project plan so decisions do not stall during testing.

How long should GLPI history logs be kept?

The retention period is a policy decision, not a technical one. GLPI lets you configure history log retention per entry type, and the GLPI 12 data and privacy documentation advises purging logs rather than keeping everything. Your ISMS should set the period based on your legal obligations, contractual needs, incident investigation requirements and data protection rules, then document it. Records that must survive for audit should be exported or archived under that policy, while personal data should follow your privacy retention rules. Ask your legal and privacy teams to confirm the period before configuring any purge schedule.

What happens to plugins and records during a GLPI 11 or 12 upgrade?

Records in the core database are migrated by the update process, but plugins need attention. According to the GLPI update documentation, you must back up the database, the files and the config directory, including glpi.key and glpicrypt.key, before replacing application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so confirm each plugin supports the target version before you start. Test incident and change workflows after the upgrade, because approval and routing behavior is where regressions usually appear.

What should a quote for this work include?

A quote should follow from a written scope that lists the process paths to configure, the approval chains, the integrations, the test cases, the migration of any existing records, the training and the handover documents. It should separate one-time work from recurring work such as upgrades, backups and support. Ask for the assumptions, the client inputs required, the acceptance criteria and what is excluded, including any audit preparation, which an accredited certification body performs. If you are considering GLPI Network subscriptions, the GLPI subscriptions page lists public cloud at 19 euros per user per month and private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted tiers starting at 100 euros per month. Confirm current terms with the vendor.

How DeployOpen scopes GLPI compliance records work

DeployOpen works from a written, fixed scope agreed before any work starts. For GLPI incident and change records, that scope names the GLPI instance and its environment, the ticket categories that count as security incidents, the problem and change workflows to configure, the approval steps and approver groups, and the history log settings to apply. It also states what is out of scope, such as your SIEM, code repositories or deployment pipelines. DeployOpen configures GLPI in infrastructure you control, so the scope must name where the instance runs, who administers it and which backups cover it. The scope does not promise an audit outcome. DeployOpen does not issue audit reports or certifications. Independent certification bodies do, and the scope should say so plainly so your ISMS team plans its own audit schedule.

Your team provides the inputs that a configuration cannot invent. That means the process owners for incident management and change management, the approved incident and change policies, the list of people who may approve standard, normal and emergency changes, and the criteria your organization uses to classify an incident. You also confirm which history log entries your retention rules must keep and for how long, and who signs off on the retention decision. DeployOpen delivers the configured workflows, business rules and approval routing, a documented mapping from each in-scope GLPI record type to the relevant Annex A controls, and an evidence pack for the ISMS team that shows how to pull ticket, problem, change and history records for an auditor. Ask any proposal to list each deliverable by name and to state which items your team must review and accept in writing.

How DeployOpen delivers GLPI compliance configuration and evidence

DeployOpen plans, configures and documents GLPI in infrastructure you control, so tickets, problems, change approvals and history logs can be shown as evidence for the Annex A incident and change controls. We start from your control set and existing processes, then agree the scope in writing before any configuration begins.

How we scope

Map your incident and change procedures to the Annex A controls your auditor will test
Agree which ticket, problem and change categories and approval steps the records must show
Define history log retention periods and purge rules in writing before go-live
Confirm which evidence your certification body expects, since DeployOpen does not issue audit reports

How we build

Configure change and problem business rules, group approval requests and validation steps in GLPI
Set up ticket categories, statuses and escalation rules that match your documented incident process
Test approval routing with sample changes and confirm history entries are written as expected
Document each configuration choice against the control it supports, with the GLPI version it was tested on

How we hand over

Deliver a control-to-record mapping that names the GLPI screens, reports and saved searches for each control
Provide a runbook for exporting tickets, change approvals and history logs for an audit sample
Walk through the evidence pack with your compliance lead and the staff who will maintain the records
Record retention, backup and upgrade procedures, including the steps required before a GLPI update

How we support

Review the configuration after each GLPI minor or major release before applying it to production
Keep the evidence mapping current when your incident or change procedures change
Ongoing support, upgrades and periodic reviews are available as a retainer after handover
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts

GLPI records for ISO 27001 incident and change management