ServiceNow Security Incident Response Requirements Workshop Questions

Security incident response requirements workshop questions are the prompts a team uses to find out how alerts reach people, how incidents are contained and recovered, who must be told and which decisions cannot be left to a tool. Each answer should become a register entry with an owner and a status.

Current Incident Detection and Alerting

How are security incidents currently detected: through automated alerts (firewalls, intrusion detection, endpoint protection), through manual monitoring (analysts reviewing logs), through external notification (customers reporting attacks), or through incident discovery (during routine maintenance)? Which detection method catches incidents fastest? Which detection methods generate the most false positives? Where are alerts currently sent: email, phone, Slack, a ticketing system? Does your incident response team see all alerts, or only escalated ones? Ask: if an intrusion detection system alerts at 2 AM, what happens? Is someone on-call? Do they respond immediately, or do alerts wait until business hours? This defines your incident response timeline and your need for automation.

Incident Classification and Severity Levels

How do you currently classify incidents: by source (malware, phishing, intrusion), by target (which system, which data), by impact (high-impact incidents affecting many users, low-impact incidents affecting one user)? Do you have defined severity levels (critical, high, medium, low)? What defines each level: is a database compromise critical, or does critical require widespread impact? Different organizations classify differently. Your classification scheme drives response speed and allocation of resources. Ask: which incidents require immediate response, which require urgent response, which can be queued for regular business hours? Define response time targets for each severity level.

Incident Investigation and Analysis Workflow

When an incident is reported, what is the investigation process: interview the person who discovered it, collect evidence (logs, memory dump, network traffic), analyze the evidence, determine the scope and impact, and identify the root cause? How long does investigation typically take: hours, days, weeks depending on complexity? Who investigates: a single analyst, a team, or does it depend on incident type? What tools does the investigator use: log analysis, forensic tools, threat intelligence? Does your organization have a formal incident investigation process documented, or does each analyst approach incidents differently? Consistent processes produce better evidence and faster resolution.

Containment and Recovery Steps

Once an incident is detected, how do you prevent it from spreading or causing more damage: do you isolate the affected system, revoke user accounts, block IP addresses, or take other steps? Who decides on containment actions: the incident responder, a manager, or requires approval? How quickly can you isolate a compromised system without disrupting operations? Recovery is the next step: restoring the system to clean state (from backup, reinstalling software, changing credentials). Can you restore systems within hours, or does recovery take days? If recovery is slow, incidents remain open longer and impact persists. Ask: do you have documented recovery procedures for critical systems, or is recovery ad-hoc?

Communication During Incident Response

Who needs to be informed during incident response: the incident responder’s manager, business owners, executive leadership, customers, regulators, legal counsel? What information do they need: incident status, timeline, impact, recovery estimate? When are they informed: in real-time, or only after incident is resolved? Does your organization have a media relations team or public affairs function that needs notice? Communication during an incident is critical: incorrect information causes panic, lack of communication causes confusion. Ask: who owns communication during incidents, how do you track who has been notified, how do you ensure consistent messaging?

Incident Response Team Structure and On-Call

Do you have a dedicated incident response team, or does incident response happen ad-hoc when someone has time? If dedicated, what is team size and expertise? Are team members on-call outside business hours, and if so, what is the on-call rotation? On-call requires having trained personnel available to respond immediately, which increases staffing costs but reduces incident impact. Ask: what is your incident response time target? A short target means you need on-call personnel; a longer one may not.

Post-Incident Review and Lessons Learned

After an incident is resolved, do you conduct a review to understand what happened, why it happened, and what could prevent it in the future? A post-incident review (also called a blameless post-mortem or after-action review) is a valuable practice that prevents repeat incidents. Ask: does your organization conduct formal post-incident reviews? Who participates: incident responder, manager, affected business owners? How are lessons learned documented and shared? Are findings escalated to management to drive systemic improvements (new tools, process changes, training)?

Incident Record and Compliance Reporting

How are incidents currently recorded: in incident tickets, in a separate incident database, in email summaries? Can you query historical incidents by type, date, or impact? Are incident records structured in a way that regulatory auditors can verify your incident response capability? Do you need to report incidents to regulators (data breach laws typically require notification if customer data is compromised)? Understand regulatory requirements: some industries require incident notification within specific timeframes. Plan how you will capture incident data to meet reporting requirements.

Who belongs in the room, and who only reads the output

A requirements workshop for incident response often fails because the wrong people answer the questions. Operations staff know how alerts actually arrive. Legal knows which notices are mandatory. Service owners know which systems cannot be taken offline on a Tuesday. Each group should be in the room for the questions it can answer, and each should receive a written copy of what the room decided, even if it did not attend.

Running the session in four blocks

1. Open with a live example, a past case from the organization’s own history that went badly, and ask the room to describe what happened in the first hour. This anchors the rest of the session in real behavior rather than in the intended process.
2. Walk through intake and classification with the monitoring leads, and write down every point where a human decides something the team assumed was automatic.
3. Move to containment and recovery with the service owners. Ask for the limits they will not accept, not the actions they would like to see.
4. Finish with legal, privacy and communications, and ask them to name the decisions that cannot be delegated to the platform.

Questions that expose requirements people have not thought about

The usual questions ask what a team does today. These ask what would change the answer, which surfaces the requirements that only appear under stress.

• What would you do differently if the same alert arrived during a planned maintenance window that nobody told the monitoring team about?
• Which of your current responders could not work the case alone, and what would they need to see first?
• If a regulator asked for the decision record of last year’s worst case, which document would you hand over, and how long would it take to find it?
• Which evidence source is held by a team outside incident response, and what happens when that team is on leave?

Turning answers into a requirements register

Answers from a workshop are not requirements until they are rewritten. Each one should become a single statement with an owner, a status and a link back to the discussion that produced it. Keep the register in a form that the design team can filter, because the same answer often affects intake, access and reporting at once.

Signs the workshop went wrong

• The output lists tools and features, not decisions, which means the room described the product rather than the response.
• Two groups give opposite answers to the same question and the facilitator moves on without recording the disagreement.
• Nobody asks what happens when the primary contact is unavailable.

Should a vendor attend the workshop?

A vendor can answer questions about what the platform does, but they should not be the source of requirements. Invite them for a short technical session after the business requirements are drafted, so the platform is fitted to the response and not the other way round.

Can the workshop run remotely?

Yes, provided the facilitator keeps a shared document open that everyone can edit during the session. Remote sessions can fail when answers are spoken and not written, so require one written answer per question before the discussion moves on.

What do we do when stakeholders disagree on severity?

Record each position with the reason behind it, and do not settle the disagreement in the room. Pass the disagreement to the governance owner with the options, because a severity model decided by the loudest person in a workshop is unlikely to survive the first serious incident.

How many follow-up sessions are needed?

Plan at least one follow-up for each group that raised a decision it could not make on the day. Treat the follow-up as part of the workshop, not as a separate project, and close it when every open decision has a named decider and a date.

The escalation criteria article covers handoffs, one of the topics the workshop may need to settle, and the roles and RACI page covers the roles that the answers will need to name.