Open source ITSM for ISO 27001

The evidence an ISO 27001 auditor looks for is a chain, not a single record. An incident ticket should point to the affected asset in the CMDB, the asset should carry a named owner as required by control A.5.9, and any change made to that asset should be a change record with a recorded approver, a test result and a back-out plan under A.8.32. When GLPI or iTop links these objects, an auditor can start from an incident under A.5.26, follow it to the asset and then to the change that fixed it, and check each step against the timestamps. Decide early which fields are mandatory at each transition (for example, no change moves to implementation without an approver and back-out plan), because an optional field is usually empty on the day an auditor samples the record.

The strength of this chain depends on the procedure behind it. A ticket that is closed without a root cause or a link to the affected asset proves only that someone clicked a button. Before go-live, document the incident, change and inventory procedures, configure the workflow and approval steps to follow them, and sample a set of closed tickets to confirm the records show what the procedure requires. Also confirm how the platform records changes to the ticket itself, since the log of who edited a record and when is part of the evidence. Ask your implementation partner to show this sampling as part of acceptance testing rather than assuming the configuration is correct.

Records also have to survive. The GLPI update procedure requires backups of the database, the files and the config directory, including glpi.key and glpicrypt.key, before any upgrade. Treat that as a minimum. Without the key files, encrypted data in the database may not be readable after a restore, so a backup that omits them is not a usable backup. Set a retention period for ticket and asset history that matches your ISMS documentation, store backups where access is controlled, and test a restore on a separate system at least once so you know the evidence can be recovered. Confirm with your partner how these backups, key files and audit logs are protected and reviewed, because an auditor will ask who can alter or delete them.

Your ITSM records have to stay retrievable for the whole certification cycle, not just for the audit week. 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. That means an auditor can sample an asset inventory entry, an incident ticket or a change record from any point in the cycle, including the months before the most recent audit. Decide early how long GLPI or iTop keeps closed tickets, historical asset states and CMDB relationships, and confirm that archiving or purge jobs do not remove records the cycle still needs. Make sure your backup scope (database, attachments and configuration) can restore a ticket as it looked at a past date.

If your ISMS still maps to the 2013 edition, treat the controls as a re-baseline rather than a copy-over. Certifications to ISO/IEC 27001:2013 had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period set by IAF MD 26:2023. Organizations that carried older control references into their ITSM configuration need to map them to the 2022 Annex A controls, including the merged controls behind 5.9 and 8.32, and check that each asset class, ticket category and change type now points to the right control. Review the ISMS documentation alongside your ITSM workflow definitions so the evidence trail reflects the current control set.

Confirm with your certification body which rules apply to your audit. Accredited certification bodies must apply ISO/IEC 27006-1:2024 to all clients, a requirement IAF MD 29:2024 set for 31 March 2026. Ask the certification body how it expects ITSM evidence to be presented, which samples it will draw from the cycle, and whether it wants read-only access or exports. Record those answers in your ISMS documentation so the GLPI or iTop configuration can be explained the same way in each surveillance visit.

Start by fixing the ISMS scope in writing, because every later decision depends on which information assets, business units and locations the management system covers. Once the scope is set, name an owner for each asset class that falls inside it. Control A.5.9 asks for an inventory of information and other associated assets that records their owners, so an owner field in GLPI or iTop should be mandatory for every asset type from day one, not filled in later. Agree the process for maintaining that inventory, including who approves new assets and who retires them. Then define the incident and change procedures that the ITSM tool will enforce. For incidents, that means documented steps that map to A.5.26, with categories, priorities, escalation paths and closure criteria. For changes, it means approval and back-out fields that match A.8.32. Write these procedures before configuring workflows so the tool reflects the documented process, not the reverse.

Pilot the platform with a deliberately small subset of assets, such as one business unit's servers and the laptops of its staff. Use the pilot to test ownership fields, ticket templates, approval rules and evidence exports, and confirm that a sample incident and a sample change can be traced from request to closure with timestamps intact. Confirm the exact features of your chosen version in its documentation rather than assuming them. Once the pilot produces records an internal auditor would accept, widen discovery to the rest of the scope, using the inventory agents and network discovery in stages. Each expansion should repeat the owner assignment and reconciliation step, so the inventory does not grow faster than its governance.