ServiceNow Discovery Requirements Workshop Questions

A Discovery requirements workshop is the session where the team settles scope, access, credentials and CMDB ownership before the first scan is set up. This page lists the questions that surface those decisions and the evidence each answer should rest on.

Network and Infrastructure Assessment

Describe your current network topology: on-premises, cloud, hybrid or multi-cloud. Document which IP ranges need to be scanned. How many servers and devices are in scope? Which network devices (switches, routers, firewalls) need to be discovered? Are there network segments or zones that should not be scanned? Document any air-gapped or isolated networks. Describe your virtualization platform (VMware, Hyper-V, KVM, or none). How many virtual machines do you have? Do you use containerization or Kubernetes? Are there legacy systems still running unsupported operating systems that may not respond to discovery probes? What is the current state of your IP addressing scheme? Are subnets well documented, or will discovery help you understand gaps?

Access, Security and Permissions

Which teams or individuals need to grant network access for Discovery scanners? Does your security team require approval before Discovery scans production systems? Can you deploy a MID Server on your network, or must Discovery remain outside your firewall? What read-only access can you grant: SNMP, SSH, WMI, HTTP APIs or others? Are there systems that should not be scanned (test labs, security-sensitive systems, third-party systems)? Does your organisation have active directory or identity management integration that can be used for discovery? Which credentials should Discovery use: shared accounts or per-system credentials? What security monitoring is in place that might flag Discovery traffic as suspicious?

Application Portfolio and Database Inventory

Which applications are critical to your business and must be discovered and mapped? Do you run commercial off-the-shelf applications (SAP, Salesforce, Oracle) that need specialized discovery patterns? Which databases are in your environment: SQL Server, Oracle, PostgreSQL, MongoDB or others? Are there applications that use non-standard ports or custom APIs that may not be discovered by standard patterns? Do you have network-attached storage or SAN systems that need to be mapped? How do you currently track application ownership, business criticality and dependencies? Where is this information stored, and how can Discovery integrate with it? Which applications are mission-critical and require high-fidelity discovery data?

CMDB Strategy and Data Integration

Do you have an existing CMDB or configuration inventory system? If so, how will Discovery data integrate with it: will it replace manual data, supplement existing data or run in parallel? What data quality standards do you have: are duplicate records acceptable or must they be deduplicated? How will you handle discovered items that do not match your naming conventions or taxonomies? Do you need to enrich discovered data with business context (owner, cost center, application name) after discovery? Who is accountable for data quality: IT operations, the platform team, or a dedicated data stewardship role? What historical data exists that should be migrated or archived during Discovery implementation?

Operational Support and Governance

Who will manage and troubleshoot Discovery going forward? Do you have sufficient expertise in-house or do you need Oblytech to provide managed support? How often should Discovery run: continuously, daily, weekly or monthly? Should Discovery run on a schedule or on-demand only? What escalation path exists if Discovery scan fails or introduces issues? How will you handle discovery of systems managed by third parties (cloud providers, managed service providers)? What warning signs indicate problems requiring investigation? How will you communicate discovery results to business stakeholders and teams who depend on the data?

Design Decision Triggers

The answers to these questions significantly change the scope, complexity and approach of Discovery implementation project. If your network has many air-gapped segments, Discovery scope expands. If your organisation restricts network scanning access, you may need a hybrid approach (some automated discovery, some manual inventory). If data quality is critical and your team is small, you may need more Discovery automation and less manual remediation. If your business has rapid change (frequent deployments, cloud adoption), Discovery frequency should increase to keep the CMDB current.

Run the workshop around the decisions it has to produce

A requirements workshop for Discovery is only useful if it ends with decisions that the implementation team can build against. The questions below are arranged that way. Each block names a decision the program cannot avoid, the questions that surface it, and the evidence the room should bring. A workshop that works through questions in the order they come to mind tends to finish with a long list of open items and no authority to close them, which is why this sequence starts with decisions rather than with the tool.

Invite the people who hold the answers, not only the people who will sponsor the work. In practice that means someone who can say which subnets are real and which are retired, someone who controls firewall change, someone who owns the credentials for servers and network devices, and someone who will read the output every week. Without the last of these, the workshop tends to produce a scope that nobody uses.

The decision sequence, in the order to take it

1. Scope boundary. Which networks, cloud accounts and sites are in the first release, and which are explicitly deferred? Ask for the address plan and the cloud account list, not a verbal summary.
2. Access model. Which collection points can reach which segments, and what change process approves each new path? Ask what happened the last time someone opened a port for a scanner.
3. Credential ownership. Who issues the accounts that discovery will use, how are they stored, and who is told when one is revoked? Ask how many discovery accounts exist today and whether any of them are shared.
4. Reconciliation intent. When discovery and an existing inventory disagree about a server, which source wins, and who decides? Teams often leave this question unanswered.
5. Operating rhythm. Who reviews failed scans, who approves changes to scan schedules, and how often does the CMDB owner meet with the discovery operator?

Questions that reveal hidden scope

The explicit inventory is rarely the whole estate. These questions tend to surface the rest, and the answers should be recorded with a name against each one.

• Which devices are managed by a supplier, a managed service or a partner, and do those parties permit remote collection?
• Which environments are built and torn down automatically, and does their lifetime match a discovery cycle?
• Which legacy systems are still in use but no longer have an owner in the directory?
• Where do database instances run inside virtual machines that the infrastructure team does not list separately?
• Which sites have unreliable links, so that collection will need to be scheduled outside business hours?

Evidence to bring to the room

What to do when the room cannot answer

An unanswered question is information. Record it in a parking list with an owner, a date by which the answer is needed and the design decision that depends on it. Do not let the workshop drift into speculative design to fill the gap. If the access question is open, the collection architecture cannot be final. If the reconciliation question is open, the CMDB load cannot be tested. Naming the dependency keeps the rest of the plan honest.

When a workshop is the wrong tool

A long workshop is not always the right format. For a small, single-site estate with one owner who knows the network well, a short written questionnaire and a single review meeting usually produce the same decisions with less time. The workshop earns its place when several teams hold conflicting pieces of the picture, or when the scope crosses an organizational boundary such as a shared data center or a regulated environment.

Common planning questions about the discovery workshop

How much preparation should the sponsor expect from attendees?

Ask each attendee for one document before the session: an address extract, a credential list, or a list of their own systems with owners. People arrive with a specific artifact to check against, and the discussion is shorter and more precise.

Should the workshop cover ongoing operations or only the initial build?

Both, but in different blocks. The build questions decide what gets installed. The operating questions decide who keeps it accurate after the project team leaves. Treat the second block as seriously as the first, since many discovery problems appear months after go-live.

Who should write up the decisions?

One person should own the decision record, and it should be separate from the meeting notes. The record lists each decision, the date it was made, the people who agreed to it and the conditions under which it would be reopened.

Next step

If your organization is preparing its first Discovery scope, the questions above give a working agenda for the first session. The security and access design for Discovery covers the credential and approval questions in more depth, and the use cases page helps you decide which outcomes the scope must serve. For background on the configuration database these answers feed, see the CMDB section. The note on discovery credential governance is useful before the credential questions are settled.