CMDB Template for Excel (Free): CI Register, Relationships, Change Log

CMDB Template for Excel (Free)

A CMDB — configuration management database — answers two questions an asset list can't: what depends on this thing? and what changed on it? When the file server dies, the asset register tells you its serial number; the CMDB tells you payroll runs on it and a change went in last Tuesday. That difference is the entire value, and you can capture a useful fraction of it in a spreadsheet — if you resist the urge to build the enterprise version.

Three sheets, deliberately minimal. Here's how to use them without falling into the trap that kills most CMDB projects.

Sheet 1: The CI Register

One row per configuration item — servers, laptops, network kit, key software and services. The columns that matter: a CI ID of your own (CI-001 — same discipline as any asset register), type, status, owner, location, and criticality. Warranty and renewal dates go here too; a CMDB that flags the certificate expiring next month pays for its upkeep on that alone.

The scoping rule that decides whether this file lives or dies: start with what would page someone at 2am. Every CMDB failure story starts the same way — a heroic attempt to catalogue every cable and mouse, followed by a database that's 40% wrong within a year and therefore trusted 0%. Twenty critical CIs kept accurate beat four hundred kept approximately.

Sheet 2: Relationships

The sheet that makes it a CMDB: CI-002 runs on CI-001. Four relationship types cover small-team reality — runs on, depends on, connects to, hosts.

This is what turns an outage from detective work into a lookup. Filter the sheet for FILESRV-01 and you have the blast radius before the first user calls. It's also the impact-assessment input for change requests: a CAB reviewing "patch FILESRV-01" with the dependency list in front of it asks better questions than one reviewing a hostname.

Sheet 3: The Change Log

Every change against a CI: date, description, change request reference, who. When something breaks, the first diagnostic question is always what changed? — and this sheet answers in seconds what would otherwise be an archaeology session in chat history. If you run a formal change process, the CR reference column ties the two systems together; if you don't, the change request template is the natural companion.

Where the Spreadsheet Version Stops

The honest limits, so you can plan for them:

• Manual drift — nothing updates the register when reality changes; accuracy is a standing chore, which is why scope discipline matters so much.
• Relationships don't cascade — the sheet shows direct dependencies, not the chain (app → VM → host → switch). Two hops deep is spreadsheet territory; five isn't.
• No integration — the change log only knows what someone types into it.

For a small IT function, or for physical-asset teams whose "CMDB" is really an operational asset register with dependencies, those limits are livable for a long time. The deeper question is which tool class you're actually in — ITSM vs CMMS covers that boundary: if your configuration items are pumps, panels, and plant that need inspection schedules and compliance evidence rather than incident tickets, you want an asset-first system. AssetOS sits on that side — assets with hierarchy, dependencies, change requests, and the maintenance layer a pure CMDB never has (IT solutions).