ITSM requirements checklist for GLPI and iTop

How to use this ITSM requirements checklist before you choose a platform

Your service desk history, asset records and change approvals probably sit in spreadsheets, shared mailboxes and tools that no longer fit how work gets done. This checklist turns ITIL scope, CMDB, integration, operations and compliance needs into testable requirements, so you can choose or build an ITSM platform on evidence rather than preference. It covers GLPI and iTop, the two open-source platforms this hub compares, and each requirement below is written so that a yes or no answer can be recorded. Start by listing who owns each area: the service desk lead for incident and request, the change advisory board for change, the asset manager for inventory, and the security or compliance lead for audit evidence. Ask each owner to rank their requirements as must have, should have or later, because a long list with no ranking makes every platform look adequate.

Once ranked, verify each item in a proof of concept or against a reference environment that resembles your own. Load a realistic sample of assets and tickets, run a discovery pass with the inventory agent on a few machines of each operating system you run, and test one approval chain and one SLA breach from start to finish. Record what passed, what needed configuration and what needed custom development, because that gap drives most of the later cost. Confirm details that this checklist does not settle: the supported database and PHP versions for the release you intend to run, the exact license terms for any extensions you need, and whether vendor support covers your target hosting model. DeployOpen plans, implements, customizes and supports self-hosted GLPI and iTop deployments in your own infrastructure. It does not issue audit reports or certifications. Independent auditors and certification bodies assess compliance, and the checklist shows which evidence your platform can produce for them.

Which ITIL processes, CMDB classes and service catalog items must the platform cover?

This table lists the functional areas an ITSM platform must cover, why each one matters, and a concrete test to run during evaluation. Use it as a test script: run each check against GLPI or iTop in a sandbox with your own process definitions, not against vendor demonstrations. Most rows will need configuration, custom fields or extensions, so the test result matters more than the feature list.

Requirement	Why it matters	How to verify
Incident management	Restores service and feeds problem and major incident reporting. Timestamps and categories must be reliable for later reviews.	Open an incident linked to two assets, escalate it to a second group, resolve it and confirm the timestamps and history are complete in the export.
Service request fulfilment	Separates routine requests such as access or hardware from break-fix work, and needs its own approvals and catalog entries.	Submit a request from the self-service portal for a standard item and confirm the approval route, fulfilment task and closure notice.
Change management	Provides authorization, testing and back-out evidence for production changes, and supports standard, normal and emergency change types.	Create a normal change with two approval levels, attach a back-out plan, reject it at level one and confirm the rejection and re-submission appear in the audit trail.
Problem management	Links recurring incidents to a root cause and a known error, so the same fault does not reappear after go-live.	Link three related incidents to one problem, record a known error and confirm the incidents show the workaround and the closure reason.
CMDB classes and relationships	Relationships (for example, application depends on server and database) drive impact analysis and change scope. A flat asset list is not enough.	Model one business service with its servers, database and network dependency, then run an impact view from a failed component and compare it with the expected result.
Asset inventory and discovery	Supports the asset register, unauthorized device detection and software licensing. Inventory must update without manual entry.	Deploy the agent to a sample of Windows, macOS and Linux hosts, then confirm hardware and software records appear and that a removed device is flagged.
SLA and OLA definitions	Sets response and resolution targets per service and per internal supplier, with breach alerts and reporting.	Assign a priority to a sample incident, let the clock run past the target and confirm the breach is recorded and shown in the SLA report.
Service catalog	Defines what users can request, who approves it and which configuration item it creates or changes.	Publish one catalog item with a required field and an approval step, then confirm the ticket and the resulting CMDB record are linked correctly.
Approval workflows and reporting	Approvals must be traceable to a named approver and retained. Reports must answer audit questions without manual extraction.	Run a sample report for changes approved in a period, export it and check that each approval shows approver, date and decision.

When GLPI fits the requirements and when iTop fits

GLPI fits organizations that want one platform covering ticketing, asset inventory, contracts and financial records, with agent-based discovery built in. GLPI describes itself as an IT service management platform for tickets, assets, CMDB, contracts, financial management and data center infrastructure, distributed under GPL-3.0. Its native inventory comes from GLPI Agent, the successor of FusionInventory Agent, which runs on Windows, macOS and Linux and also performs network discovery, package deployment and remote ESX inventory.

Native agent inventory: GLPI Agent sends hardware and software inventory to GLPI, which suits checklist items on asset inventory agents.
Broad module set: Tickets, contracts and financial management sit in the same database as assets, which reduces integration work for asset-centric service desks.
Authentication options: Internal database, LDAP, IMAP and REMOTE_USER are available, which matters when identity sources are already defined.
Documented upgrade path: The update procedure requires backing up the database, files and the config directory, and plugins are suspended after a new version is detected until reactivated.
Stack requirements: The README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs for GLPI 11.0 list PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6.

Confirm with the GLPI version you plan to deploy whether its CMDB model, SLA and approval workflows, and monitoring connectors meet each checklist item, since the answer depends on version and plugins.

Which security requirements must the ITSM platform meet?

An ITSM platform holds your asset inventory, CMDB and sensitive incident data, so it is a high-value target and an audit subject in its own right. The controls below cover who can sign in, who can see and change configuration, how sessions and keys are protected, and how administrative actions are recorded. Confirm each one against the exact version you plan to run, because capabilities differ between releases.

Authentication source order

GLPI authenticates users against its internal database, LDAP directories, IMAP mail servers and other external methods such as REMOTE_USER, tried in that order. Decide which directory is the system of record for staff, and check what happens to accounts that exist both locally and in LDAP. Test that a disabled directory account can no longer sign in, and confirm whether any local administrator accounts remain as a break-glass path. Ask the implementation partner to document the order in your configuration.

Role-based access to the CMDB

Define roles that separate who can read configuration items, who can edit them, and who can see tickets flagged as sensitive, such as security or executive requests. Map these roles to groups that come from your identity provider rather than to individual users. Review which profiles can export data or run imports, since bulk export is a common route for data loss. Confirm how the chosen version scopes visibility by entity, group and ticket type before go-live.

Step-up authentication and session revocation

The GLPI 12.0.0 release notes list step-up authentication for certain administrative actions and a view of active user sessions with the ability to revoke them. Decide which actions you want to require a second confirmation, such as changing authentication settings or granting administrator profiles. Set a procedure for revoking sessions when a staff member leaves or a device is lost. Confirm that these features work with your chosen authentication source and with any single sign-on method you add.

Backup of database, files and keys

A GLPI restore needs more than the database. The update procedure requires backing up the database, the files and the config directory, including the glpi.key and glpicrypt.key files that protect stored secrets. Losing these keys can make encrypted fields unreadable even when the database restores cleanly. Store key files separately from the database backup, restrict their access, and test a full restore into a non-production host at least once before go-live.

Audit logging of administrative changes

Administrative changes to profiles, rules, authentication settings and plugins affect every user, so they need a reliable record of who changed what and when. Confirm which events the installed version logs by default, where those logs are stored, and how long they are retained. Forward logs to your central log platform if your policy requires it, and check that logs cannot be edited by the same administrators they record. Include a test in acceptance where an administrator makes a change and you confirm the log entry.

Plugin state after upgrades

Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. This matters for security because a plugin that is disabled during an upgrade can remove an integration that enforces a control, or a plugin that is reactivated without review can introduce new access paths. Keep a list of approved plugins with owners and versions, and make plugin review part of every upgrade change record.

Which compliance evidence ITSM records must hold up to an assessment

An ITSM platform does not make an organization compliant. It produces records that assessors examine, and the value of those records depends on whether they are complete, attributable, time-stamped and kept for the period the rule requires. Before you configure anything in GLPI or iTop, decide which controls your auditor or regulator will test and which ticket, asset and change records would prove each one. For example, the HIPAA Security Rule at 45 CFR 164.312(b) requires audit controls that record and examine activity in systems containing ePHI. If your service desk touches those systems, you need tickets and change records that show who accessed or altered them, when, and under which approval, not only that a ticket was closed. The eCFR text of 45 CFR 164.312 sets out the technical safeguards in full.

Retention is the second design decision. SEC Rule 17a-4(b)(4) is one example of how long records must be preserved for certain regulated firms, in that case communications relating to the business for not less than three years. A ticketing platform that purges closed tickets or overwrites history after a fixed number of months may fail that expectation even when the workflow itself is sound. Check whether your records are kept as originals, whether attachments and comments are preserved with their timestamps, and whether database backups and archives are covered by the same retention rule. Confirm the exact retention periods and acceptable evidence formats with your auditor or regulator, because they vary by sector, jurisdiction and contract. The industry pages in this group work through ISO 27001, SOX, DORA and NIS2 in detail, so use them for control-level mapping. DeployOpen plans and configures the ITSM controls, workflows and evidence exports that support an assessment, and it prepares the records for review. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree with your assessor in advance which evidence they will accept and how they want it delivered.

What operational requirements must be verified before go-live?

How do you apply upgrades to a self-hosted GLPI instance safely?

Treat every upgrade as a controlled change with a tested backup and a rollback path. The GLPI update procedure requires you to back up the database, the files and the config directory, including glpi.key and glpicrypt.key, then replace the application files and run 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 plan time to check each plugin's compatibility. Confirm with your team who owns the upgrade window, how long a rollback would take, and whether your change process records the backup as evidence. The current release line includes GLPI 12.0.0, published on October 7, 2026, so check your version against the release notes before scheduling.

How much server capacity does an ITSM deployment need?

Sizing follows ticket volume, console users and whether the database runs on its own server. For iTop, Combodo suggests an all-in-one server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users. Larger installations move to separate web and database servers of up to 8 vCPU and 16 GB each, according to Combodo's software requirements page. Those figures are starting points, not guarantees. Ask for a load estimate based on your real ticket volume, asset count, discovery frequency and integrations, then test the design with representative data before go-live. Hosting cost depends on your own infrastructure and is not included in any software subscription.

Which PHP and database versions does GLPI or iTop require?

Version requirements differ between products and releases, so verify them against the exact version you plan to deploy. The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the GLPI installation docs for GLPI 11.0 list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 and state that only MySQL and MariaDB are supported. For iTop 3.3.x, the requirements page lists PHP 8.2 to 8.4, MySQL 5.7 or later, and MariaDB 10.6 to 11.8, with MariaDB preferred and GraphViz required. Confirm these with your platform team, pin the versions in your build, and make sure your operating system packages still receive security updates for them.

How should the web server be configured for GLPI?

The web server's document root must point to GLPI's public directory, not to the installation root, with URL rewriting that routes requests through index.php. The GLPI installation docs describe this setup for Apache, Nginx, lighttpd and IIS. Exposing the installation root can make configuration files and internal code reachable, so this check belongs in your go-live test plan. Also confirm that TLS terminates correctly, that the config directory is not web-accessible, and that session and cookie settings meet your security baseline. Ask your implementation partner to document the exact virtual host configuration and to show the test results.

How do you deploy and maintain inventory agents across the estate?

Inventory accuracy depends on agent coverage and on keeping agents current. GLPI Agent collects hardware and software inventory and sends it to GLPI, and it also performs network discovery, package deployment and remote ESX inventory. It runs on Windows, macOS and Linux and is the successor of FusionInventory Agent, according to the GLPI Agent documentation. Before go-live, define the deployment method for each platform, the target schedule, the handling of devices that never report, and the process for agent upgrades. Measure coverage against your device source of truth, such as your endpoint management tool or procurement records, and assign an owner for gaps.

What reporting and dashboards must work on day one?

Reporting requirements should be written as questions the service desk, auditors and managers will actually ask. Typical examples include open incidents by priority and age, SLA breaches, change records with approvals, assets without an owner, and software installed without a matching licence record. Confirm which of these come from standard reports and which need custom queries or dashboards, and test each one with known data. Also verify who can see which records, because access rules affect reports as well as tickets. Document the report definitions so they survive upgrades and staff changes.

What support model should you agree before going live?

A go-live needs a named support path for three layers: the open-source product, your hosting and operations, and your customizations. For GLPI, Teclib' maintains the product and offers GLPI Network subscriptions with support levels, and self-hosted subscriptions are priced by tier, with the Basic tier listed at 100 euros per month for up to 10 agents and 500 assets, according to the GLPI Network subscriptions page. For iTop, Combodo sells commercial support, training and consultancy. Clarify what each subscription covers, response expectations, who patches the operating system and database, and who handles plugin compatibility after upgrades. Ask for these terms in writing and include them in your runbook.

Who owns the ITSM platform after the implementation partner leaves?

Handover is part of go-live readiness, not an afterthought. Before acceptance, your team should own the runbooks for backups, restores, upgrades, agent deployment, user administration and integration credentials. Confirm who holds the encryption keys referenced in the GLPI configuration, how secrets are rotated, and who approves changes to the platform itself. Test a restore into a separate environment and have your staff perform at least one upgrade rehearsal. Ask your partner to deliver documentation for each of these items and to name the skills your team needs to maintain the platform.

How to scope the data to migrate from spreadsheets and legacy tools

This sequence turns scattered spreadsheets, legacy ticket queues and asset lists into a defined, reconciled data set with a tested path into the new service desk and CMDB. It ends with a cutover plan that can be reversed if counts do not match.

Inventory every existing data source
The DeployOpen team and your service desk lead list each source that holds IT service data: asset spreadsheets, procurement exports, legacy ticketing tools, contract registers, directory exports and shared knowledge folders. For each source, record the owner, the export method, the last update date and any known gaps. The step is complete when every source has a named owner and a written export method that a second person can repeat.
Classify records by business object
Sort the exported data into the object types the new platform will hold: assets, contracts, users, open tickets, closed ticket history and knowledge articles. Decide which open items move, which are archived for reference and which are retired. Agree the rule for each class with the business owners, such as keeping only the last set of years of closed tickets. The output is a classification register that states the target object type and the migration rule for each source.
Define the CMDB class model before importing
Before any file is loaded, the architect defines the configuration item classes, their mandatory attributes and the relations between them, such as which server runs which application and which contract covers which device. Import data is mapped to that model, not the other way round, so that legacy column names do not shape the CMDB. The check is a signed-off class and attribute list that maps every source column to a target field or a documented reason to drop it.
Load data with CSV import and run consistency audits
The team loads the mapped files through the platform's import tools, starting with the low-dependency classes such as locations and contracts before assets and relations. After each load, run the data consistency audits that the platform provides, and log duplicates, orphaned records and attributes that fail validation. Confirm the audit results with the data owners and correct the source files rather than editing values by hand in the target. The step closes when audits return no unresolved errors for the agreed classes.
Reconcile discovery results with procurement data
Compare the inventory gathered by discovery agents with the procurement and finance records. Each device or software item should match a purchase, a contract or a documented exception, and each purchase should be traced to a device or be explained. The reconciliation lists matched items, unmatched discovery records and unmatched purchases with an owner for each gap. The step is complete when the open gaps are small enough that the owners have accepted them in writing.
Run a pilot migration with reconciliation counts
Migrate one bounded group, such as a single site or one asset class, into a non-production instance. Compare record counts per class between source and target, and sample individual records for field-level accuracy, including relations and attachments. Record every difference with its cause and the fix applied. The pilot is accepted when the counts match or each difference is explained, and the business owners confirm the sampled records are correct.
Set the cutover and rollback plan
Agree the cutover sequence, the freeze point for the source systems, the final delta load and the reconciliation check that must pass before users are switched. Define the rollback trigger, the point after which rollback is no longer practical and the steps to restore the legacy tool to read-write use. Keep a verified backup of the source exports and the target database before cutover. The plan is ready when the approvers have signed off the trigger, the timing and the rollback steps.

What do buyers ask before hiring a partner to define ITSM requirements?

How long does ITSM requirements work take, and what drives the duration?

The duration depends on scope more than on the tool. The main drivers are the number of ITIL processes in scope, how many integrations with monitoring, identity and procurement systems must be designed, how clean the existing asset and contract data is, how many approval chains exist, and how many sites or legal entities share the service desk. A single-site service desk with two processes and one directory is a small exercise. A multi-entity estate with an existing CMDB to reconcile is a larger one. A partner should give you a timeline only after a written scope exists, and the timeline should list which workshops, data reviews and sign-offs it depends on.

What does the client need to provide for requirements work?

The work needs named people, not only a project sponsor. Process owners for incident, request, change and problem management must confirm how each process runs today and what must change. Data owners must confirm which asset, contract and license records are authoritative. The team also needs read access to the identity directory and to the monitoring platform so integration requirements can be checked against real attributes and alerts, not assumptions. Finally, someone with authority must sign off the requirements document before configuration starts. Ask the partner to list these roles in the scope so you can assign them before work begins.

Can our team define ITSM requirements without an outside partner?

Yes, for small scopes where the team already has strong ITSM knowledge and clear process owners. A single service desk with a short list of processes, a limited set of asset classes and one identity source can often be specified internally using the GLPI or iTop documentation as a guide. The work becomes harder when several sites or entities must share one CMDB, when audit evidence must map to a framework, or when the existing data is inconsistent. In those cases an outside review helps catch gaps in change approvals, CMDB relationships and migration rules before they become configuration debt.

Which costs are one-time and which recur after go-live?

Requirements, configuration, data migration and rollout are normally one-time costs under a fixed-scope agreement. Ongoing costs include platform administration, upgrades, plugin maintenance and support. For GLPI, the GLPI Network subscriptions page lists public cloud at 19 euros per user per month, private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted subscriptions from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise). For iTop, Combodo offers iTop Community free for up to 10 agents, iTop Atelier for up to 50 agents and iTop Forge for more than 50 agents, available on premises or as SaaS. Confirm which of these fees apply to your agent count and hosting model, and confirm which support level your scope needs.

How do we ask for a quote that we can compare?

Ask for a written scope in which every requirement maps to a deliverable. Each process in scope should show the workflow, approval steps, SLA rules and reports it will receive. Each integration should name the source system, the data fields exchanged, the direction of sync and the test method. Migration should list the source systems, record types, volumes you have confirmed and the cleansing rules. Acceptance criteria and the timeline should be stated per deliverable. DeployOpen works on fixed-scope engagements where scope, deliverables and timelines are agreed in writing before work starts, so a quote follows from that written scope. Ask every bidder for the same document structure so the comparison is like for like.

Does DeployOpen certify that our ITSM setup meets ISO 27001 or SOX?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies decide whether your controls meet a framework. During requirements work, the useful question is which records, approvals and timestamps an auditor will need, such as asset inventory records, change authorizations and incident histories, and whether the ITSM tool can produce them with the right retention and access controls. Ask the partner to show how each evidence item will be generated, stored and reviewed, and confirm the final assessment with your auditor.

Will the requirements cover the CMDB model and the data we must migrate?

They should, and you should check that they do. A good requirements document defines the CMDB classes you need, the relationships between them (for example, which servers support which services), the fields that must be populated, and the discovery method for each class. It should also state which existing spreadsheets, databases or tools feed the migration, which records are authoritative, and how duplicates and orphan records are handled. For GLPI, the GLPI Agent covers hardware and software inventory, network discovery and package deployment on Windows, macOS and Linux. For iTop, the CMDB model is customizable and includes CSV import and data consistency audits. Confirm which of these fit your estate before choosing a platform.

How DeployOpen scopes and delivers ITSM requirements and implementation

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source service management platforms inside your own infrastructure. For ITSM requirements, we turn the checklist on this page into a written scope, then deliver it in your cloud accounts, data centers or air-gapped network.

How we scope

We confirm which ITIL processes, CMDB classes and discovery sources are in the written scope before work starts.
We map SLAs, approval paths and service catalog items to named owners and agreed deliverables.
We list the monitoring, identity and reporting integrations and the data sets to migrate, with exclusions stated.

How we build

We install and configure the chosen platform, such as GLPI or iTop, within your hosting constraints and access controls.
We deploy inventory agents in pilot groups, then test discovery results against a reference list of known assets.
We build integrations, approval workflows and reports, and test them against the acceptance criteria in the scope.

How we hand over

We document configuration, CMDB data model, integration settings and backup and update procedures for your team.
We deliver administrator training on tickets, assets, change records and reporting tied to the agreed scope.
We provide evidence packs on asset inventory, change approvals and incident records for your compliance reviewers.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, platform upgrades and continuous testing are available as a retainer after handover.
Ask any implementation partner to confirm how upgrades, plugin revalidation and backups are covered in the quote.

ITSM requirements checklist

How to use this ITSM requirements checklist before you choose a platform

Which ITIL processes, CMDB classes and service catalog items must the platform cover?

When GLPI fits the requirements and when iTop fits

Which security requirements must the ITSM platform meet?

Authentication source order

Role-based access to the CMDB

Step-up authentication and session revocation

Backup of database, files and keys

Audit logging of administrative changes

Plugin state after upgrades

Which compliance evidence ITSM records must hold up to an assessment

What operational requirements must be verified before go-live?

How to scope the data to migrate from spreadsheets and legacy tools

Inventory every existing data source

Classify records by business object

Define the CMDB class model before importing

Load data with CSV import and run consistency audits

Reconcile discovery results with procurement data

Run a pilot migration with reconciliation counts

Set the cutover and rollback plan