ServiceNow CMDB: Roles, Responsibilities and RACI

Core Roles in CMDB Management

The CMDB Data Owner determines what gets stored, data quality standards, and retention policies. They define CI types, attributes, and relationships. The Configuration Manager maintains the CMDB, runs data quality checks, and resolves data issues. The CMDB Administrator handles user access, maintains the system, and manages integrations. The Service Owner provides their service’s configuration data and confirms accuracy. The Security Lead reviews access and audit trails.

Clear role separation prevents mistakes and provides accountability. A data owner who also manages access can grant themselves inappropriate permissions. An administrator who also approves changes can bypass controls. Separating roles creates checks.

Decision Rights and Authority

The Data Owner has authority over data structure and quality standards. They decide what belongs in the CMDB and what does not. The Configuration Manager has authority over day-to-day operations and data quality. They can run data cleanup jobs, update records, and enforce quality rules. The CMDB Administrator has authority over access control and system settings. They decide who can see or edit what data.

Service Owners have authority over their own service’s configuration data. They confirm whether relationships and attributes are accurate. They approve major changes to their services. Escalation should be clear: if someone disputes a CMDB record, who decides what is correct?

RACI Matrix for CMDB

Ownership Gaps

A common gap: who owns data quality on an ongoing basis? CMDB data degrades if nobody is accountable for maintaining it. Assign the Configuration Manager as owner of data quality and quality checks. Schedule regular quality reviews.

Another gap: who resolves disputes about configuration data? If a change request says a CI should be retired but the service owner says it is still in use, who decides? Define escalation clearly: disagreements go to the Service Owner by default, with CMDB Data Owner as final arbiter.

Who owns CMDB training? New team members need to understand what goes in CMDB and why. Without training, people bypass CMDB or enter bad data.

Integrating CMDB With Change Management

CMDB effectiveness depends on keeping it current. When infrastructure changes are made, CMDB records should be updated to reflect the new state. The best way to ensure this happens is to integrate CMDB updates with change management. When a change is approved and deployed, the change process triggers CMDB updates. This automation keeps the model current without burdening IT staff to remember to update CMDB manually.

For major changes (adding new services, retiring systems, major reconfigurations), CMDB updates can be required steps in the change workflow. For minor changes (updating an IP address, changing a service owner), automated API calls to CMDB can happen after the change is deployed. The goal is to make CMDB updates a natural part of how work gets done, not an afterthought.

Data Quality Governance

Establish data quality standards: which fields are required? Which relationships must exist? What data age is acceptable? Run periodic data quality reports to find gaps and stale data. Assign the Configuration Manager to review and fix issues. Build data quality maintenance into regular operations, not as a one-time project.

Access Control and Segregation of Duties

Use role-based access. Not everyone needs to see all configuration data. Infrastructure teams see infrastructure CIs. Application teams see application CIs. Security teams see security-relevant attributes. Use role-based queries to restrict what each role sees in reports and dashboards.

Separate create/modify/delete permissions by role. Service Owners can update their own services but not others. Configuration Managers can update CIs but need approval for large bulk changes. CMDB Administrators can change system settings but not CMDB data.

Starting with the decisions the CMDB team will actually face

Role charts for a CMDB often begin with job titles and end with a grid of letters, and the grid often does not survive the first disputed record. A more useful starting point is the list of decisions that come up every month: a team wants a new class of item, a relationship no longer matches the architecture, an application owner says a server is still in use when discovery says it is gone, a security review asks for a field to be hidden. Each of those is a decision, and each needs one person who can make it, a clear set of people who must be consulted, and a route for appeal. Once those are written down, the roles can be assigned to fit them rather than the other way round.

Work through the list with the people who have actually made these calls in the past. The gaps often show up in the decisions that nobody could name, such as who approves a bulk retirement of many records after a cloud account is closed. Those gaps are where a CMDB quietly fills with contested data.

A decision-rights table for the recurring disputes

The table below is a shape you can adapt. It deliberately separates the person who decides from the people who must be consulted, because a consultation step that is treated as approval is a common cause of ambiguity.

The last column matters most. A dispute that has no defined tie-break can be settled by whoever is most senior in the room, which is not the same as being accountable for the data. Write the tie-break into the operating procedure and review it after the first few contested cases, because the real pattern of disputes is often not what the chart predicted.

Separating the roles that check each other

Some combinations of role should not sit with one person, even in a small team. The configuration manager who runs the reconciliation should not be the only person who signs off the reconciliation exceptions. The administrator who grants access should not be the sole reviewer of who received access. In a small organization these separations are hard to achieve, and the practical answer is often a second reviewer drawn from a neighboring team rather than a formal structure. Record the compensating control explicitly so an auditor can see it was a choice. The access design page is the place to record that compensating control.

Also check whether the same person is both a steward for a class of items and the owner of a service that depends on it. That overlap is not wrong, but it means the steward is marking their own homework on quality questions, and the review should be routed to someone else for those items.

Standing up the roles in the right order

1. List the decisions from the table above and confirm each one with the people who have made it before, adding any the team has faced in the last year.
2. Name a data owner with authority to settle conflicts across classes, even if that authority is rarely used. Without one, every dispute becomes a meeting.
3. Assign a CI steward to each class with a named list of fields that steward may change, and state which fields they may only propose changes to.
4. Name the CI steward and service owner roles using the ownership model as a reference, then confirm each service owner has the time to review relationships. A role that exists on paper but has no protected time is a common reason relationship data goes stale.
5. Set the access that each role needs in the platform, and check it against the decision-rights table so that no role can act on a decision it is not meant to make.
6. Run one realistic exercise: pick a contested record from the past year and walk it through the table. Adjust the table wherever the walk-through stalled.

Situations where a grid is the wrong format

A RACI grid works when there are several teams, each with a clear set of tasks. It becomes noise when the same two people do almost everything. In a small team with one administrator and one configuration owner, a short written note about who decides what, with the escalation route, is more useful than a full matrix that nobody reads after the first meeting. The grid can be introduced later, once the number of teams that touch the CMDB makes the overlaps real.

Questions that surface once the roles are in place

Who approves an emergency change to a CI that has not been reviewed yet?

The change authority for the emergency should approve the operational action, and the CMDB record should be updated by the steward after the event, with the reason noted. Do not let the emergency path bypass the record entirely, because the next incident can be investigated against a model that no longer reflects what was running.

Can a service owner hand their role to a deputy?

Yes, but the handover should be recorded as a change to the role assignment, not as an informal email. Without that record, the deputy’s decisions cannot be traced back to delegated authority, and the next dispute can expose the gap.

What if the data owner and the security lead disagree about field visibility?

Escalate to the risk owner for the affected business service. Visibility is a risk decision, and the data owner should not be the one deciding whether a risk is acceptable on their own data. The outcome should be written into the access design so it does not come back as a new argument next quarter.

How do we know the roles are working?

Look at the age of open disputes and at how many were settled by the tie-break rather than by agreement. A high share of tie-breaks often means the decision rights are unclear, not that people are difficult. Review those cases with the people involved and rewrite the table entry that caused them.

Next step

The governance model is the natural companion document, and the two should be reviewed together.