ITSM Glossary: ITIL, CMDB, CAB

ITSM terminology tends to get written for career IT operations staff, full of acronyms that assume you already know the framework. If you're a project or engineering lead who just needs to understand what's being discussed in a meeting, here's the same terms in plain language, without the assumption that you've read the whole ITIL manual.

What Does ITSM Actually Stand For?

ITSM stands for IT service management, the general practice of designing, delivering and supporting IT services in a structured, repeatable way rather than ad hoc firefighting.

What Is ITIL?

ITIL, the IT Infrastructure Library, is the most widely used framework of best practices for ITSM. It's not software and it's not a certification your company needs, it's a shared vocabulary and process model that most ITSM tools and conversations are built around.

ITIL Is a Framework, Not a Rulebook

Teams often assume ITIL has to be adopted wholesale or not at all. In practice, most organizations use it selectively, borrowing the incident and change management concepts while skipping the parts that don't fit how they actually work.

What Is a CMDB?

A CMDB, configuration management database, is a record of IT assets, called configuration items, and how they relate to each other, which server supports which application, which application depends on which service.

Why a CMDB Matters During an Incident

When something breaks, a CMDB is what lets a team answer what else does this affect quickly, instead of manually tracing dependencies during an active outage.

What Is a CAB?

A CAB, change advisory board, is the group that reviews and approves changes before they go into a production environment, weighing risk against the value of the change.

A CAB Can Slow Teams Down If It's Not Scoped Carefully

Routing every minor change through a full CAB review is a common complaint from engineering teams. Most mature ITSM setups separate low risk, standard changes from major ones, so a CAB only reviews what actually carries real risk.

What Other Terms Come Up Often?

Incident, Problem and Change Are Often Confused

An incident is the fire. A problem is why the fire keeps starting. A change is what you do to stop it from happening again. Treating a recurring incident as a one off, instead of opening a problem record to find the root cause, is one of the most common ITSM mistakes outside dedicated ops teams.

What Other Roles Show Up in ITSM Conversations?

• Service owner, accountable for a specific service end to end, including its performance and cost

• Incident manager, coordinates the response during a live incident until service is restored

• Change manager, runs the CAB process and owns the overall change management workflow

• Problem manager, owns root cause investigation after an incident is resolved

Small Teams Rarely Have a Person Per Role

In a smaller organization, one person often wears several of these hats at once, the same engineering lead might act as change manager and incident manager depending on the week. The roles are useful as a checklist of responsibilities that need covering, not a hiring requirement.

How Does This Apply to Project and Engineering Teams Specifically?

Most of this vocabulary was built around IT operations, but it shows up in software delivery too, especially anywhere what is the workflow of project management software overlaps with production releases. A deployment is a change. A production bug is an incident. A recurring bug class is a problem. The framework maps cleanly onto engineering work even when the team never formally adopts ITIL.

What Does a Typical ITSM Workflow Look Like End to End?

Seeing the terms connected in sequence makes them easier to remember than reading each definition in isolation.

• A user reports an issue through the service desk, which logs it as an incident

• The incident gets resolved, restoring service, even if the root cause isn't fixed yet

• If the same incident keeps recurring, a problem record gets opened to investigate the underlying cause

• Fixing the problem usually requires a change, which goes through the CAB if it carries meaningful risk

The Whole Flow Exists to Separate Urgency From Root Cause

Restoring service quickly and fixing the actual cause are different jobs with different timelines. Keeping incident and problem records separate is what lets a team stop the bleeding now without being blocked on a slower root cause investigation.

Where Does This Fit With CMMI Style Workflows?

Regulated or process heavy teams often run ITSM concepts alongside CMMI level process discipline. If your team is working through how to set up a CMMI compliant workflow, change and incident tracking usually need to sit inside that same structured process rather than in a separate, disconnected system.

Do You Need a Dedicated ITSM Tool for This Vocabulary to Matter?

Not necessarily. If your primary need is customer facing IT service desk ticketing with formal CAB workflows, a Jira Service Management alternative built specifically around service desk operations will have more out of the box support for these concepts than a general project tool. Sanplex is built more around product and engineering delivery than IT service desk operations, and it's worth being upfront about that rather than stretching a project tool to cover a role it wasn't designed for.

Terms Explained Quickly

What's the difference between a help desk and a service desk?

A help desk typically just handles reactive issue reporting. A service desk is broader, covering requests, incidents and the single point of contact for all IT interactions, not just problems.

Do small teams need a formal CAB?

Usually not a full board. A lightweight approval step for risky changes, even just one senior engineer signing off, covers most of the same risk reduction without the overhead.

Is a CMDB only useful for large enterprises?

Smaller teams benefit too, even an informal, manually maintained list of what depends on what saves real time during an incident, it doesn't require enterprise tooling to be useful.

What's the difference between ITIL v3 and ITIL 4?

ITIL 4 shifted from a strict process based model to a more flexible value stream approach, but the core vocabulary, incident, problem, change, CMDB, carried over largely unchanged.

Does agile development conflict with ITSM practices?

Not inherently. The friction usually comes from applying heavyweight change approval to every deploy. Teams that scope CAB review to genuinely risky changes tend to run agile delivery and ITSM discipline side by side without much conflict.

If change and incident tracking need to live next to the actual delivery work instead of a separate ITSM tool, sanplex.com covers how that fits together, or a quick call with the team can go through specifics for your setup.