Open source ITSM with GLPI and iTop: what a service desk needs before you choose
Most IT teams that want to replace a commercial service management tool, or stop running incidents, requests, changes and assets out of spreadsheets and shared mailboxes, start with the wrong question. The useful question is not which tool has the longest feature list but what your service desk must prove and connect to. GLPI and iTop are the two open-source platforms in scope here, GLPI under GPL-3.0 and iTop under AGPL-3.0, and the right choice depends on your process model, the state of your asset data and the integrations you cannot give up. This page is written for CISOs, CIOs, heads of IT and service management leads at regulated organizations who need an ITSM platform that holds up to audit, not only one that looks tidy in a demo.
Before comparing products, write down the process model you actually run. Decide which ITIL practices are in scope for the first release (incident, service request, change, and the configuration data behind them), who approves changes, what evidence an auditor will ask for, and which records must be kept and for how long. Then inventory your asset and configuration data: how many sources hold it, how current it is, and whether ownership of each configuration item is clear. Ask the platform team to confirm which of these two products models your change approval paths and relationships between configuration items without heavy customization, because that drives the amount of custom work later.
Map the integrations early, because they set the scope of the project. Identity (directory sync for requesters, technicians and approvers), monitoring alerts that should open incidents, endpoint discovery and the commercial tool you are leaving all carry data and access decisions. Confirm with the vendor and in a proof of concept which connectors and APIs are native and which need custom development, and who will own them after go-live. Treat the answers as inputs to the written scope, because they determine what your implementation partner must estimate and test.
What an open source ITSM rollout must settle before choosing GLPI or iTop
Most GLPI or iTop projects stall on questions that were never answered, not on configuration. The six decisions below set the process scope, the data model, the ownership of CMDB quality, and the evidence the business needs, so the platform choice follows from real requirements.
First-phase ITIL processes
Decide whether incident, request and change all go live together or in sequence. Incident and request usually come first because they carry the daily volume, while change needs approval workflows, CAB roles and a link to CIs before it can be trusted. GLPI handles ticketing and asset records in one product, while iTop models change and CI relationships more explicitly. Write down the process scope before comparing platforms.
Authoritative asset and CI sources
Name the system of record for each asset type before discovery runs. Endpoints, servers, network devices, cloud resources and licenses often exist in several tools, and a CMDB that imports all of them without precedence rules will hold conflicting records. Agree which source wins for hostname, owner and status, and which fields only the CMDB may edit.
CMDB ownership and data quality
Assign a named owner for CMDB content and a separate owner for each CI class. Define who approves new CI types, who resolves duplicates, and which completeness checks run each month. Without this, the CMDB decays within months of go-live and change impact analysis stops being reliable, regardless of which platform you choose.
Day-one identity and monitoring integrations
List the identity and monitoring feeds needed on the first day, not later. Typical examples are directory-based user and group sync for requesters and approvers, and alert feeds from monitoring that open incidents linked to affected CIs. Confirm which connectors each candidate provides out of the box, which need custom work, and who maintains them after handover.
Audit evidence the business must produce
Identify the evidence auditors or regulators will ask for: records of who approved each change, when incidents were closed, and how access to the ITSM tool itself is logged. Map these to your control framework before configuring workflows, because mandatory fields and approval steps are what produce the evidence. Ask each candidate how audit logs are retained and exported.
User channels: portal, email and phone
Decide which channels create tickets and how each one maps to a request type and priority. Email-to-ticket and a self-service portal are common starting points, while phone intake usually needs a manual or telephony-linked step. Each channel changes the form design, the notification templates and the staffing model, so settle them before building the service catalog.
GLPI, iTop and the other open-source options: when each fits
This table compares GLPI and Combodo iTop as ITSM platforms and places the open-source helpdesks beside them. Read each row against your own service catalog, change volume and CMDB ambition, then confirm feature parity and plugin support against the exact version you plan to deploy.
| Dimension | GLPI | Combodo iTop |
|---|---|---|
| License | GPL-3.0; GLPI 12.0.0 published October 7, 2026 | AGPL-3.0; iTop 3.3.0 published September 15, 2026 |
| Process model and CMDB emphasis | ITIL service desk built around asset records and tickets; CMDB-style relationships are present but less central | CMDB-centered; configuration items and their relationships drive incident, request and change workflows |
| Asset inventory and discovery focus | Strong inventory of hardware and software with agent-based and network discovery options; confirm which connectors your version supports | Inventory is modeled as configuration items; discovery usually depends on connectors or imports you configure and maintain |
| Typical fit | Smaller or mid-sized service desks that need ticketing, asset tracking and a simpler catalog | Organizations where change control must reason about dependencies between applications, services and infrastructure |
| Change control | Change records and approvals are available; confirm the depth of approval and impact analysis you need | Change impact follows CI relationships, which suits CMDB-driven change advisory boards |
| Operating effort | Lower modeling effort at start; ongoing plugin and version upgrades need a named owner | Higher data modeling effort up front; continuous CI data quality work is the main recurring cost |
| Helpdesks (Zammad, FreeScout, osTicket) | Not a substitute for ITIL service management; fits customer support queues when the need is support, not change control | Same as GLPI: helpdesks suit customer support channels, not CMDB-driven ITSM |
Reference architecture: the components an open source ITSM stack needs
An ITSM stack built on GLPI or iTop is a set of connected parts rather than a single application. Each component below runs inside your own cloud accounts, data centers or air-gapped network, and each needs a defined plan for availability and recovery before the first ticket is logged.
ITSM application server and web tier
The GLPI or iTop application runs the service catalog, incident, request and change workflows, and the CMDB user interface. Place the web tier behind a reverse proxy with TLS termination in your own network zone, and keep administrative access on a separate path. For high availability, run at least two application nodes behind a load balancer with shared session handling and a common file store for attachments. Confirm with the vendor which components must be clustered and which can run as a single instance.
Ticket and CMDB database
The database holds every ticket, approval, configuration item and relationship, so it is the record your auditors will ask about first. Plan replication to a standby instance in a second availability zone or site, and test failover rather than assuming it works. Define recovery point and recovery time targets with the business owner before choosing a topology, and confirm which database engines and versions the chosen release supports in your environment.
Discovery and inventory collectors
Agents on endpoints and collectors on network segments feed hardware, software and network data into the CMDB. Decide where collectors run, how they authenticate to the central server, and how often they report, because stale inventory is the most common reason a CMDB loses trust. Scope discovery ranges carefully, especially in operational technology or regulated segments where scanning can disrupt systems. Ask the implementation partner how collector failures are detected and reported.
Directory and SSO connection
Directory integration controls who can log in, which groups receive approval rights, and when access is removed after a leaver event. Connect the ITSM application to your directory service over encrypted channels, use a dedicated bind account with least privilege, and map directory groups to service desk roles explicitly. Confirm which SSO protocols the chosen release supports and whether group-to-role mapping requires custom development.
Monitoring feed and event intake
Monitoring tools create incidents automatically when a service degrades, and this feed must not flood the queue or bypass the change process. Define which alerts open tickets, how duplicates are merged, and which configuration items they reference, so that CMDB relationships stay useful during an outage. Route the feed through a single integration point with authentication and logging, and test it during planned maintenance before relying on it for severity one events.
Backup, logging and audit trail
Backups must cover the database, uploaded attachments and configuration files together, because a restored ticket without its attachment or approval history loses its evidentiary value. Store copies outside the production failure domain, encrypt them, and run restore tests on a schedule you can document. Forward application and access logs to your central logging platform so that changes to workflows, approvals and CMDB records can be reviewed. The HIPAA Security Rule's audit controls provision, cited in 45 CFR 164.312(b), is one reason healthcare teams keep these records searchable.
Build, partner or buy SaaS for open source ITSM
This table compares running GLPI or iTop with your own team, running it with a fixed-scope implementation partner, and buying commercial ITSM SaaS. Read each row as a question to answer for your organization: who holds the data, who keeps the skills, and who patches the platform. The main takeaway is that open source shifts cost from license fees to people and operations, so the right choice depends on the skills and accountability you can sustain.
| Decision factor | In-house on open source | Open source with a partner | Commercial ITSM SaaS |
|---|---|---|---|
| Control over data and hosting | Full control. Data stays in your cloud accounts, data centers or air-gapped network. | Full control kept in your environment, with the partner working inside agreed access boundaries. | Data sits with the vendor in its hosting regions. Confirm locations, tenancy and export rights in writing. |
| Skills the team must keep | Database, web server, PHP or application administration, ITIL process design, CMDB data stewardship and integration engineering. | A named product owner and administrator who understand processes and data. The partner covers build and specialist work. | Configuration and process administration skills. Platform engineering is left to the vendor. |
| One-time cost | Internal project time for design, data cleanup, integration and testing. Infrastructure setup. | Fixed-scope build, configuration, integration, data migration and handover, quoted from written scope. | Implementation and configuration services, often from the vendor or a reseller. Confirm what is included. |
| Recurring cost | Staff time for operations, upgrades, patching, backups and support. Hosting and monitoring. | Hosting, licenses for any paid add-ons, and an optional retainer for upgrades, security patches and support. | Subscription fees per user or module, usually with tiers. Check for price increases and add-on charges at renewal. |
| Upgrades and security patches | Your team tests and applies releases, including security updates to the application and its dependencies. | Shared or contracted. The partner can test and apply releases under the retainer, and you approve change windows. | Vendor applies platform updates. Confirm release notice periods, your testing window and any customizations that break on upgrade. |
| Evidence for audits | You generate and retain change, incident and asset records, access reviews and configuration history yourself. | Partner documents configuration, procedures and handover evidence. You still own the operational records. | Vendor supplies some audit reports and logs. Ask which evidence you can export and whether it meets your assessor's needs. |
| Exit path | Exit is mostly a data export and migration you plan and run. Keep the database schema and export tools documented. | Define data export formats, documentation and handover terms in the statement of work so you can move away. | Exit depends on export formats, API access and contract terms. Ask for a tested export of tickets, assets and relationships. |
| Questions to ask a SaaS vendor | Not applicable | Not applicable | Where is data stored and backed up? Which audit reports and logs can we export? What is the notice period for changes? What is the full export format and cost on exit? |
| Questions to ask a partner | Not applicable | Who maintains upgrades and patches after handover, and at what response times? What is in fixed scope and what is a change request? How are data and admin access handled? | Not applicable |
How an open source ITSM rollout runs, phase by phase
The sequence moves from agreed processes and data scope to a hardened platform, tested integrations, a controlled cutover and a handover your team can operate and upgrade without us. Each phase closes with a named output you can review before the next one starts.
Agree process design and roles
We run workshops with your service desk, change advisory board, asset owners and security team to map current incident, service request and change workflows, then document the target versions. Roles covered include who logs, triages, approves, implements and closes each record type, along with escalation paths and the categories used for reporting. The closing output is a signed-off process map and RACI matrix. The step is done when each process owner has approved the map in writing.
Define the data model and CMDB scope
We decide which configuration item classes the CMDB will hold, such as servers, applications, network devices, business services and licenses, and which relationships matter for impact analysis and change risk. Each class gets defined attributes, mandatory fields, naming rules and an owner for the source of truth. The output is a data dictionary and a scope statement that lists what is excluded for the first release. The step is complete when the data owners confirm the dictionary and the scope in writing.
Build and harden the platform in your environment
We deploy GLPI or iTop into your own cloud account, data center or isolated network, using the infrastructure and change controls your organization already requires. Work includes database and web tier configuration, TLS, administrator account separation, backup and restore design, logging, and removal of default or unused components. The output is a build record, a hardening checklist with each item marked as applied or accepted with a reason, and a documented restore test. Hardening is complete when your security team reviews the checklist and the restore result.
Integrate identity and monitoring
We connect the platform to your directory service for single sign-on and group-based role assignment, and to your monitoring tools so alerts can open incidents with the right configuration item and priority. Each connection is tested with named test accounts and sample events, including what happens when a user leaves or an alert clears. The output is an integration test report listing each flow, expected result, actual result and any open defects. The step is done when the report is accepted and defects are assigned owners.
Migrate and reconcile data
We extract records from spreadsheets, a legacy CMDB or a commercial ITSM platform, transform them to the agreed data dictionary, and load them into a staging environment first. Reconciliation checks compare record counts, mandatory field completeness, duplicate asset identifiers and relationship integrity against the source, and each exception is either corrected or accepted by its owner. The output is a reconciliation report and a list of accepted exceptions. Migration is not considered complete until the data owners sign off on the report for each class. Ask in advance how your current vendor exports data, since export formats and history retention vary.
Run a pilot with one team
We select one team whose incidents, requests and changes are representative of your environment, and run the agreed processes with them for a fixed period set in the written scope. We track defects, workflow gaps and user questions, and adjust forms, categories and notifications based on what the pilot shows. The outputs are a pilot results summary, a defect log with status, and an updated process map where changes were made. The pilot closes when the process owner confirms the workflows work as designed.
Cut over to production
We schedule the cutover with your change advisory board, freeze changes to the legacy tool, perform the final data load, and repeat the reconciliation checks against production. We then switch intake channels such as email-to-ticket and the portal, and confirm monitoring integrations are live. Rollback steps are rehearsed before the switch. The outputs are a cutover record, the post-load reconciliation report, and a confirmed rollback plan. Cutover is complete when the first live incidents and changes have been processed through the new platform and reviewed.
Hand over runbooks and an upgrade plan
We deliver operational runbooks for backup and restore, user and role administration, integration troubleshooting, data quality checks and routine maintenance. We also deliver an upgrade plan that covers how new releases of the chosen platform are tested in a non-production copy, how security updates are prioritized, and who approves each change. Your staff run a supervised session on the runbooks before we step back. The outputs are the runbook set, the upgrade plan, and a handover acceptance record. Ongoing support and upgrades can be added as a retainer if you want them.
Which systems the ITSM platform must connect to, and what each involves
An ITSM platform is only as accurate as the data flowing into it. Each connection below sets a direction of data flow, a system owner and a failure mode that will show up in the service desk if nobody watches it. Confirm the owner and the sync rules for each one before the first configuration change.
Directory and identity provider
The directory is the source of truth for user records, groups and the people who requested or approved a ticket. Usually the ITSM platform pulls users and groups from the directory and delegates login to the identity provider over SSO. Confirm which attribute is the unique key for a person, since a changed email address or a second directory can create duplicate requester records. Agree in writing who owns group-to-role mapping, because a wrong group decides who can approve a change.
Monitoring platform for event-driven incidents
Monitoring alerts should open or update incidents automatically, but without deduplication every flapping host becomes a new ticket. The monitoring team typically owns alert rules and thresholds, while the service desk owns routing and priority. Confirm how the monitoring tool identifies an alert so the ITSM platform can match it to an open incident, and decide who closes the incident when the alert clears.
Endpoint and network discovery
Discovery feeds inventory and configuration items into the CMDB, so the data is only as current as the last scan. Scanners for endpoints, network devices and cloud accounts often report the same asset under different names or addresses. Confirm the reconciliation rule, which identifier wins (serial number, hostname, MAC address) and how retired assets are marked, or the CMDB will fill with stale configuration items that no incident can trust.
Email for ticket intake and notifications
Many requests still arrive by email, and the platform must turn inbound messages into tickets and send replies without looping on automatic messages. The mail team owns the mailbox, forwarding rules and sender authentication, while the ITSM team owns parsing and templates. Confirm how threads are matched to existing tickets, and test out-of-office and bounce handling before go-live so notifications do not flood requesters or create duplicate tickets.
HR source for joiner and leaver requests
Joiner, mover and leaver events trigger access requests, asset assignments and account removals, so the HR system is the trigger for much of the service catalog. HR usually owns the employment record and the effective dates, while IT owns the resulting tickets and fulfillment. Confirm which HR status changes create tickets, how a late-entered termination is handled, and who approves emergency removals, since a delayed leaver ticket is an access risk.
Source control and deployment tooling
Linking changes to the commits and releases that implement them lets the change process show what was deployed and when. Pipelines usually push deployment records to the ITSM platform, while change owners approve the request before the pipeline runs. Confirm which pipeline stages write records, whether emergency changes can bypass approval, and how the platform handles a deployment that never gets a matching change record, which is the most common gap in audit evidence.
What audit evidence an open source ITSM platform can support
An open source ITSM platform can supply real evidence for access management, change management and asset inventory, but only if you decide up front which records count as control evidence and configure the platform to keep them. Ticket history, approval records, change records, access logs and CMDB snapshots each map to a different control question. Ticket history and approval steps show who requested a change, who approved it and when it was implemented, which is the core of change management evidence. Access requests and their approvals support access management, provided the platform records the approver and the grant or removal date. CMDB snapshots and inventory exports show what assets existed at a point in time, which supports an asset inventory control. Before an assessment, map each control your auditor will test to a specific record type in GLPI or iTop, and confirm with the auditor which sample period and format they expect.
The audit log is only evidence if it is turned on and retained. HIPAA's Security Rule at 45 CFR 164.312(b) requires audit controls that record and examine activity in systems containing ePHI. An ITSM platform can support that requirement when it logs authentication, record access and configuration changes, and when those logs are kept under a documented retention period and reviewed on a schedule. Confirm in your own environment which events each platform logs by default, where the logs are stored, who can alter or delete them, and whether they are forwarded to a central log store. Default settings often cover less than an examiner will ask for, so test a sample event end to end before you rely on it.
Keep the ITSM ticket system separate from your communications archive unless counsel and compliance confirm otherwise. SEC Rule 17a-4(b)(4) requires broker-dealers to preserve originals of communications received and copies of communications sent relating to the business, including inter-office communications, for not less than three years. A ticket comment or a change note may be a business communication in some firms, but a service desk is not designed as a compliant communications archive, and its retention, search and immutability features need to be assessed against that rule. Ask your compliance team to classify ticket content before the platform is designed, and document the decision. Finally, DeployOpen prepares the systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination.
How much effort does open source ITSM implementation take?
What drives the total effort of an open source ITSM implementation?
Total effort follows the scope written down before work starts, mainly the number of processes, the number of integrations, the volume of data to migrate and the CMDB scope. Each incident, request and change workflow needs design, configuration, testing and training. Each connection to a directory, monitoring tool or procurement system needs its own build and test cycle. Migration effort grows with the number of asset records, tickets, contracts and relationships you carry over, and with how clean that data is today. A CMDB limited to servers and business services is far smaller than one that maps applications, network devices, cloud resources and their dependencies. Ask any implementation partner to break its quote down by these drivers so you can see which ones you can reduce.
Can an internal IT team implement GLPI or iTop without a partner?
Yes, a capable internal team can implement GLPI or iTop alone, provided it has ITSM process knowledge, database and web server administration skills, and protected time for the work. Both products are open source and carry no per-user license fee, so the question is about people and time rather than software purchase. The usual gaps are not the installation but the design decisions: ticket categories, approval paths, CMDB class model, discovery scope and reporting. Teams also underestimate the ongoing work of keeping the platform patched, backed up and aligned with changing processes. Decide early who owns the platform after go-live, and whether that person can absorb the work alongside day-to-day service delivery.
What does the client need to provide for an ITSM project?
The client provides the people and access that an implementation cannot supply on its own. Typical needs include:
- Process owners for incident, request, change and problem management who can make decisions and sign off designs.
- Data owners for assets, locations, applications and contracts who can confirm which records are correct and which should be retired.
- Read access to Active Directory or another directory, plus accounts for the monitoring and discovery tools you plan to connect.
- A test environment, a named group of test users and a realistic set of sample tickets and changes for acceptance testing.
Without these, timelines slip because design questions wait for answers and integrations wait for credentials. Confirm the exact list, owners and availability in the written scope.
How long does an open source ITSM implementation take?
The duration is set by the written scope, not by a standard number of weeks. The schedule depends on how many processes go live in the first phase, how many integrations are included, how much data must be cleaned and migrated, and how quickly the client returns decisions and test feedback. A phased plan, such as service desk and asset inventory first with change management and extended CMDB later, is a common way to reduce risk. Ask for a milestone plan with named dependencies on the client side, and for the acceptance criteria that close each phase.
What does ongoing ITSM support cost compared with internal staff?
Ongoing support is a recurring cost, and it can be met in two ways. A retainer buys a defined amount of upgrades, patching, backup checks, configuration changes and support hours from an outside team, billed under a written agreement. Internal staff cost is the salary, benefits and time of administrators who own the platform full time or part time. Both models also carry hidden costs: the internal option needs cover for holidays and turnover, and the retainer needs clear rules for what falls outside its hours. The most useful comparison is the same list of duties priced both ways. Ask a partner to quote the retainer against a defined list of tasks and frequencies.
Why does a fixed scope matter for ITSM implementation cost?
A fixed scope fixes what gets built, what gets delivered and when, so the budget reflects an agreed set of outcomes rather than an open-ended number of hours. DeployOpen typically works under fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work begins. Changes that add processes, integrations or migration sources are handled as written change requests with their own cost and schedule impact. This makes it easier to compare quotes, because each one describes the same work. It also protects both sides: the client knows what it is buying, and the implementer knows what counts as done.
Do GLPI and iTop have license costs that affect the budget?
GLPI is licensed under GPL-3.0 and iTop is licensed under AGPL-3.0, so using either product does not require a per-user or per-device software license fee. The budget therefore centers on infrastructure, labor, integrations and support. Two points still need checking. First, confirm the license terms of any extensions, plugins or connectors you plan to use, since they may carry their own terms. Second, if you plan to offer a modified version to users outside your organization, review what the AGPL obligations require for that use. Ask your legal team to confirm these points before you finalize the design.
What to ask an open source ITSM implementation partner before signing
Start with scope, because most ITSM projects fail on data before they fail on software. Ask the partner how they will define the process scope for incident, request and change before any build starts, and how they will decide which CMDB classes (servers, applications, network devices, user endpoints) are authoritative in GLPI or iTop and which are imported from discovery. Ask who signs off the data model, which fields are mandatory for each class, and what the partner will do with records that have no owner. Ask which platform version they recommend and why. For GLPI, confirm whether they are proposing the 12.0.0 line published on October 7, 2026 or an earlier branch, and whether that choice matches your upgrade policy. For iTop, confirm the same against the 3.3.0 release published on September 15, 2026. Ask for the hosting model in writing, including where the database, attachments and discovery agents live.
Next, test the integration claims. Ask how identity integration will be built, including directory synchronization for requesters and technicians, group-based roles, and what happens to an account that is disabled in the directory but still owns open tickets. Ask how monitoring events will create or update incidents, what deduplication rules apply, and which test cases prove that a critical alert opens exactly one incident. Ask for the acceptance criteria for each integration in writing, along with the test evidence they will hand over. On migration, ask how reconciliation is verified: record counts by class and status, a sample of records checked field by field against the source system, and a named owner for each discrepancy. A migration from a commercial ITSM tool should end with a signed reconciliation report, not a statement that the data "looks right."
Finally, settle the operating questions before signing. Ask for a handover package that lists every deliverable by name: configuration export, data model, workflow definitions, integration runbooks, backup and restore procedure, and an audit evidence guide describing which change records and access logs exist and where they are stored. Ask who patches and upgrades the platform after go-live, who monitors security advisories, and how long a security patch takes to reach production under the retainer or support terms. Ask how audit evidence is produced for change approvals and privileged access, and where it is retained. Confirm that DeployOpen prepares these controls and records, while independent auditors issue any assessment. Last, ask what happens to data and configuration if the engagement ends: export formats, the timing of handover, and who holds the keys to the database and backups. Get each answer in the statement of work, not in a sales call.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For open source ITSM, the work starts with a written scope covering the service desk, asset inventory and CMDB, and the identity and monitoring connections your processes depend on.
How we scope
- Written scope agreed before work starts, listing which ITIL processes, queues and categories are in and out.
- Inventory of data sources for discovery, asset records and CMDB relationships, with ownership named for each.
- Confirmation of the identity provider, monitoring tools and change calendar the ITSM platform must connect to.
How we build
- Installation of GLPI or iTop in your cloud account, data center or air-gapped network, with configuration of the chosen platform.
- Configuration of incident, service request and change workflows, approval steps, SLA definitions and notification rules.
- Testing of discovery, integrations and workflow paths, with security hardening and backup routines verified before go-live.
How we hand over
- Documentation of configuration, workflows, data model, integrations and operating procedures as deliverables in the written scope.
- Evidence packs mapping ITSM records, change approvals and access logs to the controls your assessors ask about.
- Knowledge transfer sessions for administrators and process owners, with the runbook left in your possession.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review of platform releases and security advisories, with upgrade work scoped and agreed in writing.
- Periodic checks of CMDB accuracy, discovery coverage and integration health, reported against the agreed scope.
