ITLedger is a CMDB and IT operations platform with a ready structure, optional onboarding, connected service work, Sentinel and Richard AI assistance.

How does ITLedger onboarding work?

Customers send only the spreadsheets, exports or documentation they want loaded into ITLedger. We import that material, create relationships where the supplied information supports them, and let the customer review the result in the application.

What does ITLedger Sentinel show?

Sentinel brings findings from deliberately enrolled assets and active checks into one explainable attention queue. It supports certificate expiry, licence compliance, vulnerability exposure, external monitoring signals, source freshness, and explicitly mapped custom checks. Severity, thresholds, evidence, and operational impact remain visible.

Is onboarding credited when we subscribe?

Eligible paid onboarding can be credited against the first year of a qualifying annual subscription. Scope, eligibility, timing, and any non-creditable custom work are defined in the commercial proposal.

Is ITLedger always better than broad CMDB platforms?

No. Broad platforms may be better for deep global workflow customisation and organisations with dedicated platform teams. ITLedger is strongest when a lean team wants a working model and migration outcome without designing a large platform programme.

ITIL assumes a CMDB you probably don't have yet

Short answer

ITIL assumes a CMDB. Its most popular practices - incident management, change enablement, problem management - quietly presuppose that you know your configuration items: what exists, who owns it, and what depends on what. Small teams adopt the workflows and skip that foundation, then discover their incidents have no impact context and their changes have no dependency awareness. The fix is not an enterprise CMDB programme. It is a minimum viable data foundation: your 20 to 50 most operationally important assets, named owners, and a handful of relationship types, kept visible and reviewed.

Key takeaways

ITIL works as designed only when CI data is trustworthy; the workflows assume it exists.
Without CIs, incidents lose impact analysis, changes lose risk assessment, and problem management loses pattern detection.
The minimum foundation is small: top 20-50 assets, real owners, three to five relationship types.
The failure mode to avoid is the big-bang CMDB project that tries to model everything before delivering value.
Uncertain data should stay visible as uncertain - a CMDB that guesses is worse than one that admits gaps.

ITIL's quiet assumption

Read the ITIL 4 practice guides and a pattern emerges. Incident management talks about prioritising by business impact. Change enablement talks about assessing risk before approval. Problem management talks about analysing trends across incidents. Each of these sentences contains an invisible dependency: impact on *what*? Risk to *which* services? Trends across *which* components?

That invisible dependency is service configuration management - the practice that maintains information about configuration items (CIs) and their relationships. ITIL treats it as one practice among many. In reality, it is the data foundation under the others. Workflows route work; CI data explains what the work is about.

What breaks without CI data

Incident management without CIs is triage by gut feel. A priority gets assigned from the caller's urgency, not from the affected service. "The database is down" arrives with no way to see which applications, certificates, and teams that database supports - so impact is discovered during the outage instead of before it.

Change enablement without CIs is approval theatre. The change advisory question - what could this break? - has no data behind it, so approval becomes a signature on trust. The change that reboots a server also restarts three applications nobody remembered it hosted.

Problem management without CIs has nothing to correlate. Recurring incidents look like isolated bad luck because there is no shared component to pivot on. The pattern was there; the data model just couldn't see it.

None of this means the workflows are wrong. It means they are running on an empty tank.

The minimum CMDB that makes ITIL land

The good news: the useful foundation is much smaller than the enterprise diagrams suggest.

The top 20 to 50 operationally important assets - the applications, servers, databases and certificates behind your most important services. Not every laptop.
Named owners for each - a person or team who can answer for it, with a deputy where it matters.
Three to five relationship types you will actually use - "runs on", "depends on", "owned by", "secures", "processes data for". Skip the other forty.
A review habit - a short recurring look at what went stale, unowned, or unresolved.

With that in place, incident prioritisation gains impact context, change assessment gains a dependency answer, and problem management gains something to correlate. ITIL starts working the way the books describe.

Why teams skip the foundation anyway

If the minimum is this small, why do so many teams run ITIL workflows on spreadsheets? Because the visible alternative is the traditional CMDB project: months of modelling workshops, hundreds of object types, a data-cleaning marathon before anyone is allowed to benefit. Teams correctly sense that this trade is not worth it for them - and then overcorrect to no foundation at all.

The bounded alternative looks different: start from a ready model rather than designing one, import the sources you already have under review, and keep the unresolved questions visible instead of silently guessing them away. That is exactly how ITLedger onboarding is structured - and if you want the broader playbook first, our guide on setting up a CMDB without a consultant walks through the scoping.

The honest caveat about data quality

A CMDB that presents guesses as facts is more dangerous than an empty one, because people act on it with confidence. Whatever route you take, keep the distinction visible: which records were reviewed, which relationships are evidence-backed, and which matches are still candidates awaiting a human. In ITLedger, uncertain candidates stay visible for review rather than being imported silently - your incident and change workflows should only ever stand on approved ground.

FAQ

Do small IT teams need a CMDB for ITIL?

Yes, but a small one. Incident, change and problem management all presuppose CI data - impact, risk and trend analysis are impossible without it. The practical foundation is the top 20-50 operationally important assets, named owners, and a handful of relationship types, not an enterprise-wide model.

What is a configuration item (CI) in ITIL?

A configuration item is any component that needs to be managed to deliver an IT service - applications, servers, databases, certificates, network devices, documents, and the relationships between them. ITIL's service configuration management practice maintains this information so other practices can use it.

Which ITIL practices depend most on CI data?

Incident management (impact and prioritisation), change enablement (risk assessment of what could break), and problem management (correlating recurring incidents to shared components) benefit most directly. Service continuity and availability work follow close behind.

How do we start without a big CMDB project?

Start from a ready model instead of designing one, import the sources you already have under review, and keep unresolved questions visible rather than guessed. A bounded, reviewed import of your top assets delivers the foundation in a scope a small team can actually finish.