ServiceNow Vulnerability Response Requirements Workshop Questions

Security, IT operations, application teams and compliance use this workshop to decide how findings reach the platform, who triages them, who owns each fix and how fixes are checked. The question lists group each topic with what the answer means for the design.

Vulnerability identification and intake

Where do vulnerabilities come from? Automated scanners (Nessus, Qualys, OpenVAS), penetration testing (external or internal), bug bounty programs, vendor advisories, third-party dependency scanning, or manual discovery?

How are vulnerabilities reported? To a ticketing system, email, a specific security mailbox, or directly into Vulnerability Response?

What metadata is captured for each vulnerability? CVE ID, severity, description, affected systems, data sources, date discovered, evidence (screenshots, test results)?

Impact on design: if you have multiple vulnerability sources with different data formats, you need data mapping and normalization. This is effort. Plan for it.

Vulnerability assessment and triage

Who triages vulnerabilities? A security team member, an automated rule set, or both?

What is the triage criteria? Severity level, affected system criticality, business context (is the vulnerability in a production system or test system)?

How long does triage take? Same day, next business day, weekly batch? This determines how long vulnerabilities sit waiting for review.

Warning sign: if triage takes longer than a week, vulnerabilities are aging in the system without decisions. This slows remediation.

Remediation planning and ownership

Who owns remediation? The team that owns the affected system, a centralized security team, or shared responsibility?

How are remediation responsibilities assigned? Automatically based on system ownership, manually by a security team member, or negotiated with system teams?

What is expected in a remediation plan? Timeline, specific fix (update library, apply patch, implement workaround), owner, and success criteria?

Impact on design: if teams own remediation, you need clear accountability and escalation paths. If security owns it, you need security resources dedicated to this work.

Testing and validation of remediations

How is remediation tested? Re-scan with the same scanning tool, independent testing by security team, or acceptance by the system owner?

What is the timeline for testing? Same day as remediation, next business day, or within a week?

Are remediations tracked with evidence? Do you store the re-scan results or security sign-off in Vulnerability Response?

Warning sign: if remediation is not validated systematically, vulnerabilities reported as fixed might still be open. This undermines credibility of the system.

SLAs and escalation

What SLAs do you need? Response time (how quickly is a vulnerability reviewed), remediation time (how quickly is it fixed), and closure (how quickly is it validated and closed)?

SLAs typically vary by severity: critical items get the shortest response and fix windows, high items get longer ones, and medium items the longest. Set the exact windows with the owners of the affected systems.

What happens if SLAs are missed? Who escalates and to whom?

Impact on design: SLAs drive workflow routing and notifications. If SLAs are tight, you need automated escalation. If SLAs are loose, manual escalation is sufficient.

Reporting and dashboards

What reports do you need? Vulnerability status by system, by team, by severity, by age? Remediation progress? Aging vulnerabilities? Trends (are we fixing vulnerabilities faster)?

Who needs reports? Executive dashboards for leadership, operational reports for teams, detailed reports for audits?

What frequency? Daily, weekly, monthly?

Impact on design: reporting requirements drive data quality and update frequency. If you need real-time dashboards, data must be constantly updated. If monthly is sufficient, batch updates are fine.

Compliance and audit requirements

What compliance frameworks apply? PCI DSS (credit cards), HIPAA (health), SOX (financial), ISO 27001 (information security)?

What audit evidence is required? Vulnerability inventory, remediation plans, closure evidence, escalation approvals?

How long must records be kept? Retention depends on applicable regulation.

Impact on design: compliance requirements drive audit trail logging and document retention. Plan for data archival and long-term storage.

Using workshop findings

Document workshop answers and decisions. Share the findings with your implementation team and stakeholders. Use the workshop findings to drive requirements and design decisions throughout the implementation.

Running the workshop as a set of decisions, not a discussion

A requirements workshop on this module goes wrong when it ends with a page of notes and no list of decisions. The notes capture what people said. The design needs something narrower: for each question, who decided, what they decided, which records or rules that decision drives, and when it can be revisited. Set up the sessions so that every question produces a line in a decision log before the group moves on, even when the line says the decision is deferred and to whom.

Split the work into three sittings rather than one long session. The first covers what counts as a finding and what counts as closed, because every later answer depends on those two definitions. The second covers ownership and the authority to act, which is where the decisions about approvals and exceptions sit. The third covers the evidence the organization must keep and how long it must keep it, which is where the expectations should be written down, and the audit trail evidence piece covers what an audit trail should record. Separating them stops the ownership debate from absorbing the time that the definitions need, and it gives the people who are only needed for one sitting a reason to attend.

The questions that decide the design

Most questions in a standard list are about process. The ones below are about the edges, where the platform would otherwise make a silent choice for you. Each row shows the answer that lets the design proceed, and the answer that tells you the workshop needs another session before continuing.

Preparing the room before the first sitting

1. Send the definitions of finding, closure and exception to every attendee in advance, and ask each person to bring one example from their own estate where the definition is hard to apply.
2. Bring a sample export from the current tracker, with real host names removed, so the discussion stays on how records behave rather than on abstract categories.
3. Name a scribe whose only job is to write the decision log in the same wording the group agreed, and read each line back before the group moves on.
4. Invite the owner of the configuration management data to the second and third sittings, because ownership questions cannot be settled without knowing which host belongs to which group. Map each group to its assignment group before the sitting so the ownership rules refer to real routing targets.
5. Agree in advance who can make a binding decision in the room, and who can only recommend one for later approval.
6. Close each sitting by reading out the open items, who will answer each one and when.

The harder questions that rarely make the first list

Three questions cause the most rework once build starts, and they are easy to skip because they feel like detail. The first is whether a finding can be shared with a team that does not own the host, for example a shared platform group that needs to see a weakness in a service it depends on. The answer determines the access model and the notification routing. The second is what happens when two business units hold different views of the same shared component. A single record cannot hold two owners, so the workshop needs a rule for primary ownership and for how the second unit’s concern is recorded. The roles and RACI reference is the place to check the primary owner rule against existing responsibilities. The third is whether a finding that was accepted as a known risk on one host should be checked against other hosts running the same component. Without that check, an acceptance can quietly spread across the estate without anyone deciding it should.

Each of these produces a design change, not just a policy note. Record it as one, with the decision, the rule that implements it and the test that will show it works.

Frequently asked questions about the workshop

Which attendees can join later?

Report readers add little to the definition sittings and can pull the discussion toward presentation rather than rules. Invite them to the final sitting, where the reporting questions are answered and the people who will read the output can say what they need to see.

What if two business units give opposite answers to the same question?

Do not average them. Record both positions, identify which one the organization’s risk owner has authority over, and escalate the difference as a deferred decision with a named owner. A design built on a compromise nobody owns tends to fail at the first audit that asks who decided.

Is it worth running a separate workshop for each business unit?

Run one shared set of definitions for the whole program, and check group ownership against the assignment groups governance guide, then run a short unit-specific sitting for the things that differ, such as approval routes and change windows. Repeating the definitions in every unit produces slightly different versions of the same rules, which is harder to correct later than to prevent now.

How do we record a question the room cannot answer at all?

Add it to the decision log as an open question with the reason it cannot be answered, the person who will answer it and the design areas that wait on the answer. Keep the list visible until the last line is closed, so that the build does not quietly assume an answer nobody has given.