ServiceNow Discovery: Roles, Responsibilities and RACI

Key Roles in Discovery Operations

Discovery Administrator: owns the Discovery configuration, probe deployment, and scan scheduling. Responsible for making sure scans run reliably and on schedule. Expertise: network topology, probe management, and ServiceNow Discovery module.

CMDB Manager: owns the Configuration Management Database, reconciles discovery findings with the CMDB, and maintains data quality. Responsible for resolving conflicts when Discovery finds something different from what is recorded in the CMDB. Expertise: IT asset management and CMDB governance.

Network Administrator: provides network access for probes, configures firewall rules, and validates network connectivity. Responsible for supporting discovery probe communication with infrastructure. Expertise: network infrastructure and security.

System Owner (by system type): owns a specific application or infrastructure system. Responsible for confirming that Discovery findings match actual infrastructure, correcting errors, and providing context about their system. Expertise: a specific system (database, web server, SAN, etc.).

Operations Manager: uses discovery data to improve operational visibility and CMDB accuracy. Responsible for feedback on data quality and recommendations for additional scans. Expertise: IT operations and incident management.

RACI Table for Discovery Activities

Escalation Paths

Data Quality Issues: if Discovery findings do not match actual infrastructure, escalate to System Owner first. If the system owner cannot explain the discrepancy, escalate to CMDB Manager to investigate whether the CMDB or the discovery data is wrong.

Scan Failures: if a discovery scan fails, escalate to Discovery Administrator. If it is a network connectivity issue, escalate to Network Administrator. If Discovery Admin cannot resolve it, escalate to Ops Manager to prioritise.

Configuration Questions: if a system owner wants to know how Discovery is configured for their systems, the Discovery Administrator answers. If they want to change the configuration (add more probes, change scan frequency), that request goes to the Discovery Administrator who escalates to CMDB Manager for approval.

Ownership Gaps to Clarify Before Starting Discovery

Who owns the decision to change discovery scope? Is this the Discovery Admin unilaterally, or does it need CMDB Manager approval? Clarify before conflicts arise.

Who owns the CMDB—is it CMDB Manager or Operations? If Operations owns the CMDB, they should be Accountable for reconciling discovery findings. If CMDB Manager owns it, they drive reconciliation.

Who decides which systems are in scope for discovery? Is this based on the CMDB (if it is there, discover it) or business priority (only discover critical systems)? This decision shapes the discovery strategy.

Who pays for discovery licenses and probe infrastructure? This affects priority and scale decisions. Make ownership explicit early.

Communication and Feedback Loops

Discovery Administrator: reports monthly to CMDB Manager on scan health, completion rates, and any systemic issues.

CMDB Manager: reports quarterly to Operations and System Owners on data quality metrics and reconciliation status.

System Owners: provide feedback to CMDB Manager on discovery accuracy within an agreed time of receiving findings. This feedback loop is critical for accuracy improvement.

Skillset Requirements

Discovery Administrator needs to understand network protocols (SNMP, SSH, WMI), probe deployment, and ServiceNow configuration. System Owners need deep knowledge of their specific systems. CMDB Manager needs to understand data governance and ITIL principles.

Cross-training reduces single points of failure. If the Discovery Admin is the only person who can configure probes, the team is vulnerable. Ensure more than one person can handle critical roles.

Continuous Improvement of Discovery Processes

As your discovery programme matures, refine your processes. Improve sensor accuracy. Automate reconciliation where possible. Expand discovery scope to additional systems as confidence grows. Document lessons learned and share across the discovery community in your organisation.

Where discovery ownership actually breaks: the handoffs

Role charts for discovery tend to be drawn around people, but many failures happen between them. A network engineer opens a path for a collection point and assumes the discovery operator will notice when scans start. The discovery operator sees records appear and assumes the CMDB owner has approved them. The CMDB owner assumes the network team will say if a segment was retired. Each person did their part, and the records still went wrong. The fix is to define the handoffs as explicitly as the roles, because accountability is often lost at the handoff.

For a service owner, the practical question is which handoffs need a written artifact and which can rely on a conversation. A useful test is whether the receiving party could act on the handoff without asking the sender a single question. If they could not, the handoff needs a record.

Five handoffs that need a named artifact

Setting up a new site as an ordered procedure

1. Name one accountable owner for the site. This person is the escalation point for scan failures there, even if three teams do the work.
2. Agree the segment list and the device classes expected in it, so the first scan has something to be compared against.
3. Record the collection point’s host, its maintenance window and the person who can restart it when no one else is available.
4. Run a limited first scan and have the site owner review a sample of the results, not the full output.
5. Decide who approves the first promotion to the CMDB and write that decision into the governance record.
6. Schedule the first review at a fixed interval and note who attends it.

Decision rights that a RACI does not capture

A RACI matrix shows who does what. It does not show who can stop the work. For discovery, three decisions need their own line in the governance record: who can pause collection on a segment because it is causing an outage, who can exclude a class of device permanently, and who can override a reconciliation result when the operational record is clearly wrong. Each of these is a power that can damage the data if used carelessly. Naming them separately prevents a situation where everyone assumes someone else holds the power, or where a junior operator makes the call under pressure.

Signs the role model is failing

• The same records are reopened in every review because nobody owns the reason they were excluded.
• Scan failures are reported in a chat channel but nobody records them against a segment.
• The discovery operator holds the only working knowledge of a collection point.
• Approvers sign off large batches without opening them, usually because the batches are too big to review.

The last of these is the most serious. A batch that cannot be reviewed in the time allowed is a sign that the scope is too wide or that the promotion cadence is wrong, not a reason to approve faster.

Questions about discovery responsibilities

Can one person hold both the operator and the approver role in a small team?

Sometimes, if the team is small and the approvals are sampled rather than complete. Record that the person holds both roles, add a second reviewer for changes to exclusions, and review the change history more frequently than usual.

Who owns a discovery failure that started with a firewall change?

The owner of the change owns the failure to notify, and the discovery operator owns the diagnosis. Agree this in writing before it happens, so the incident review does not turn into an argument about blame.

How often should the handoff list be reviewed?

Review it whenever a team changes its structure, and at a fixed interval otherwise. A list that was accurate at go-live tends to drift within months as people move on, so the review should check names as well as process.

Get a second view on your ownership model

If discovery ownership is contested between teams, walk through the handoffs with the people who own each side and decide which need records. For the wider ownership question, the note on CMDB ownership is a useful companion. For the operating side as a managed service, see the Discovery managed support service page.

Related guides: ServiceNow Discovery Governance Model.