ServiceNow Threat Intelligence Requirements Workshop Questions

Workshop Goals and Structure

The questions in this workshop establish your threat landscape and how threat intelligence will be tracked and used: which threats and sources matter today, the use cases for incident response, prevention and actor tracking, integration with security operations, how threat data is classified and protected, who owns the work, and how intelligence flows into day-to-day workflows. Later sections separate the questions that change the design from those that only collect opinions, and name the answers that should stop the project.

Run the workshop with cross-functional attendees: security analysts, incident responders, threat intelligence team (if you have one), IT operations, and security leadership. Plan a series of sessions, scheduled around attendee availability. Use these questions as a guide; adapt based on your organization.

Threat Landscape and Current State

What threats does your organization face: malware, nation-state actors, ransomware, insider threats, supply-chain attacks? Different threats require different response strategies. Prioritize which threats are most relevant to your organization.

Where do you currently track threat intelligence: external threat feeds (from vendors like Mandiant or Recorded Future), internal incident logs, threat forums, vendor bulletins, or news? Do you centralize threat tracking or is it scattered across multiple tools? What gaps exist in your threat visibility?

Do you have a dedicated threat intelligence team, or are these responsibilities embedded in incident response or security operations? How much time do analysts spend on threat intelligence versus other security work?

Threat Intelligence Use Cases

How do you currently use threat intelligence in incident response: do you correlate observed indicators of compromise with known threat actor TTPs (tactics, techniques, procedures)? Can analysts quickly determine if an observed attack matches a known threat actor or malware family?

Do you use threat intelligence for prevention: do you block known malicious domains or IPs at the firewall or endpoint? Are threat feeds from commercial vendors integrated into your security tools?

Do you track threat actor targeting: are certain threat actors known to target your industry or company? How do you stay informed of new threats targeting your specific organization?

Integration with Security Operations

How would threat intelligence integration help: would enriching incidents with threat actor information improve incident classification? Would automation (automatically tagging incidents as likely ransomware based on malware signature) reduce manual work?

What external threat feeds would be most valuable: commercial feeds (Mandiant, Recorded Future, CrowdStrike), open-source feeds (MISP, AlienVault OTX), or industry-specific threat sharing (financial sector, healthcare)? Different feeds cost differently and provide different coverage.

How current does threat intelligence need to be: would daily updates suffice, or do you need real-time threat updates? Real-time feeds are more expensive and require more infrastructure.

Data Classification and Privacy

What information about threats and incidents can be shared externally: can you share threat indicators (domains, IPs, hashes) with industry partners or threat intelligence platforms? Are there privacy or confidentiality constraints?

How do you classify threat intelligence: is threat information restricted to security teams, or can it be shared with IT operations and business units? Broader sharing improves threat awareness but requires clear communication and governance.

Threat Intelligence Team and Responsibilities

Who should be responsible for threat intelligence in ServiceNow: should it be managed by security operations, incident response, or a dedicated threat intelligence team? Does your organization need to hire or grow this capability?

What knowledge and skills are needed: threat intelligence analysis, malware analysis, incident correlation? Do existing staff have these skills, or do you need to train them or hire specialized expertise?

Threat Intelligence Workflow Integration

Consider how threat intelligence flows into your incident response: when a malware signature is detected, does ServiceNow automatically tag the incident as likely malware and suggest relevant playbooks? When an IP address is known malicious, does the system flag it? This automation reduces mean time to respond and improves consistency. However, automation requires accurate threat intelligence feeds and careful configuration to avoid false positives (flagging legitimate activity as malicious).

Plan for false positive handling: threat intelligence may flag legitimate activity incorrectly. Your security team must be able to quickly review and dismiss false positives. Build this feedback into your workflow: when an analyst dismisses a threat intelligence flag as false positive, log it. Over time, this feedback improves threat feed accuracy for your environment.

Design Decision Impacts

Integrating external threat feeds into ServiceNow means you must keep feeds current and maintain accuracy. Feeds from multiple vendors may contain conflicting or duplicative data; you need processes to reconcile them. Plan for ongoing feed maintenance.

Automating threat classification based on threat intelligence means your response playbooks must account for the classifications. If an incident is automatically tagged as ransomware, incident responders should follow ransomware playbooks. Automation is only useful if processes align with it.

Questions that change the design rather than collect opinions

A requirements workshop for threat intelligence is useful only if its answers change what gets built. Many workshops produce a long list of wishes that all sound reasonable and cannot be ranked, so the design team ends up guessing. The questions below are chosen because each answer narrows a decision: which sources to connect, which actions may be automated, which teams receive the output, and how much history the platform must keep. Ask them in the order shown, because later answers depend on earlier ones.

Ahead of the first session, invite every participant to share a recent case from their own work, with the steps they followed and roughly how long each step took. Real examples can keep the room away from hypothetical design.

Running the sessions so that answers are usable

1. Start with the automation boundary question, because it sets how much the rest of the design has to be trusted.
2. Record each answer in the exact words of the person who gave it, and tag it with the role, not the name, so it can be reviewed by someone who was absent.
3. Read back any answer that conflicts with another one before moving on. Conflicts found in the room are cheap to settle, and conflicts found in testing are expensive.
4. Close each session by listing decisions taken and questions still open, with an owner for each open question.
5. Circulate the record and invite corrections within a set window, after which the answers are treated as the requirements.

Answers that should stop the project

Some answers mean the work is not ready, and the honest response is to pause. If nobody can name the team that will review intelligence hits, the platform will fill with items nobody owns. If the asset records that threats would be matched against are known to be unreliable and nobody has a plan to improve them, matching can produce false confidence. If the sharing rules for the intelligence are unknown, do not design any outbound flow until they are confirmed.

Should the workshop include business unit leaders?

Include them for a single session that covers exposure and decision rights. Their views on which threats matter to the business are valuable, but detailed technical questions in front of them slow the room and make the discussion less candid.

What if the room cannot answer a design question?

Log it as an open item, naming who will close it and by when, and do not fill the gap with a plausible guess. A guessed answer can be treated as a requirement later, and it will be expensive to unwind.

Is it worth asking vendors to attend?

Only after the internal answers are recorded. Vendors are better at answering questions about their own feeds than questions about your processes, and an internal view first keeps the sessions from being driven by a sales agenda.

What is the minimum output a workshop should produce?

A written record of the automation boundary, the named owner for each receiving team, a list of asset coverage gaps, and the retention answer. If those four exist, the design can begin even when other questions remain open.

Related guides: ServiceNow Requirements Workshops That Produce Decisions, ServiceNow Threat Intelligence Use Cases for Enterprise Teams and ServiceNow Security Operations and Incident Response.