ServiceNow Security Incident Response Best Practices

Security incident response is the set of decisions and actions a team takes from the first alert to the post-incident review: how severe the case is, who holds it, what evidence is kept, how containment proceeds, and what the company must disclose.

Define Incident Severity Levels and Escalation Triggers Clearly

Not all security incidents are equally urgent. A malware infection on an isolated development machine is concerning but not an emergency; unauthorized access to your customer database is a crisis. Define incident severity levels based on impact: severity 1 for incidents affecting customer data or services, severity 2 for incidents affecting internal systems, severity 3 for policy violations or failed controls. For each severity level, define what immediate actions are required: a severity 1 incident triggers immediate escalation to your security leadership and business continuity team; a severity 3 incident is logged and investigated as capacity allows. Document these criteria and train your security team and key managers so everyone can make consistent severity judgments. When the first indicator of an incident arrives (a flagged malware detection, a suspicious account, unauthorized network access), your team should be able to quickly categorize severity and trigger the appropriate response.

Establish a Rapid Response Team Structure and Decision Authority

Incident response requires coordination across technical, legal, communications, and executive functions. Designate an incident commander who makes decisions during the active phase of the incident, a technical lead who coordinates investigation and containment, a communications lead who manages internal and external messaging, and an executive sponsor who oversees impact assessment and business decisions. Build a call tree so that key people can be reached immediately when a severity 1 incident occurs. Pre-authorize certain containment actions so that your technical team does not waste time getting approval for immediate actions: isolating a compromised server should not require executive sign-off. However, actions with broader impact, such as taking services offline or disclosing a breach publicly, should require executive decision. Train this response team through tabletop exercises at least semi-annually so they understand their roles and can work together effectively.

Document Investigation Procedures and Preserve Evidence Forensically

When a security incident occurs, your instinct may be to shut down affected systems to stop the damage. However, if you do not preserve evidence first, you will lose investigative data that could reveal how the attack occurred and whether it spread beyond your initial awareness. Before any system is powered down or rebuilt, capture memory images and disk images of potentially compromised systems. Work with your legal counsel or a forensic investigator to understand evidence preservation requirements: law enforcement or regulators may need specific evidence if the incident becomes a criminal investigation or a regulatory inquiry. Build procedures that balance rapid containment with evidence preservation, perhaps isolating a compromised system from the network to stop lateral movement while capturing data locally.

Coordinate Forensic Investigation With Containing Active Threats

Incident investigation has two parallel tracks: stopping the current attack and determining what already happened. While forensic teams are analyzing system logs and reconstructing what occurred, your security operations team should be verifying that the attacker cannot continue to access your systems. Search your environment for similar indicators: if you found malware on one server, are other servers infected with the same malware? If someone accessed one user account, did they access other accounts with the same privileges? Use threat intelligence about the attacker’s methods to harden your other systems against the same attack vector. Complete initial containment quickly (hours) so you can focus on investigation and recovery (which may take days or weeks). Create a remediation plan that tracks what must be fixed to close the vulnerability and prevents similar incidents in the future.

Assess Breach Scope and Manage Disclosure and Legal Obligations

Depending on the type of data involved and your jurisdiction, you may have legal obligations to disclose a breach to customers, regulators, or law enforcement. Work with your legal counsel early in the incident to understand notification timelines and content requirements. Scope the breach carefully: which customers were affected, what specific data was exposed, when was access first detected. Document your response timeline and the basis for your determination that a breach occurred. Different regulations have different notification timeframes: some require notification within a fixed number of days, others require immediate notification. Some incidents may be reportable to regulators (such as healthcare or financial regulators), others to law enforcement, or both. Involve your legal counsel, privacy officer, and communications team in these decisions so notification is handled according to regulatory requirements rather than being an afterthought.

Perform Post-Incident Review and Update Your Security Program

After an incident is contained and recovery is complete, conduct a post-incident review that examines what happened, why your existing controls did not prevent it, and what changes are needed. Conduct this review blameless: focus on process and system issues rather than individual errors. Identify root cause: did a security control fail, was a control missing, did people misunderstand a process, or was there an unknown vulnerability? Build a remediation plan addressing root causes and track completion. Some remediations are quick (patching a known vulnerability), others are structural (upgrading to a security scanning platform you lacked). Use lessons from this incident to improve your incident response procedures, detection capabilities, and forensic processes. Share lessons learned across your organization so that what you learned from this incident helps prevent similar incidents in other teams.

The first-hour decisions the on-duty manager must make

The manager who is paged for a live security case has a short list of decisions that cannot wait for the full picture. Severity is the first. Scope is the second, and it is usually wrong at the start. Ownership comes third: someone must be named as accountable for the case, even if that person is only holding it until a specialist joins. Writing these decisions down in the first hour matters more than making them perfectly.

The default column is deliberately conservative. A manager who raises severity on thin evidence can lower it an hour later with a reason written down. A manager who waits for certainty may spend the first hour of an intrusion waiting. Settle each seat’s remit before the pager goes off, with the roles and RACI page as a reference.

A decision log that survives shift changes

Many response failures at shift change are not technical. The incoming person reads a ticket that says what happened and nothing about what was decided or why. The fix is a decision log kept in the work notes of the incident, with one entry per decision and a fixed format.

• The decision, in one sentence, with the time it was made.
• The evidence the decision relied on, linked to the record rather than pasted.
• The person who made it and the person who approved it, if approval was needed.
• What would make the decision wrong, so the next reader knows what to watch for.

Sequencing evidence capture against isolation

Isolating a host is a decision that can destroy some evidence, such as volatile memory and live network state. Capturing that evidence takes time, and waiting can let the attacker move. The manager does not have to choose one or the other in the abstract. The useful question is which evidence the team would lose by isolating now, and whether that loss matters to the decision in front of them.

1. Name the one or two artifacts that would be lost on isolation, and capture them if the capture takes less time than the risk of waiting.
2. Isolate at the network layer first, so the host stops talking to other systems while it is still running.
3. Record the time of isolation in the decision log and note which artifacts were taken before it.
4. Leave the remaining artifacts to the investigator, with the expectation that they are collected from the isolated host, not the production network.

Tabletop exercises that test decisions rather than tools

A tabletop exercise for this role should not be a walkthrough of screens. Give the manager a scenario in which the first report is ambiguous, the severity is disputed by two stakeholders, and the only specialist on call is busy with another case. Then time how long it takes to write the first decision entry. Teams that run the exercise this way often find the gap is in ownership and communication, not in the platform.

Practices that look sound but slow the response

• Waiting for a complete timeline before sharing any update with leadership, which turns a manageable case into an escalation.
• Keeping the manager hands-on in the technical work, so nobody is available to take the next decision.
• Creating a new channel for each incident and archiving the old one before the decision log is complete.
• Treating severity as fixed once set, even when the scope grows during the first hour.

What if the severity is disputed by a business owner?

Record both views in the decision log, keep the higher severity in force until the evidence supports a change, and set a time for the next review. The dispute is itself a reason to pull in the executive sponsor, because the owner of the affected service often carries the cost of a wrong call.

Who is allowed to close an incident that the manager opened?

Closure should belong to the person accountable for the outcome, which may not be the person who opened the case. The manager can close only after the containment decision, the scope statement and the remediation owner have all been recorded in the log.

Should the manager stay hands-on during a live case?

Generally no. A manager who is also running queries or changing configuration cannot take the next decision on time. If the team is too small to separate the roles, agree in advance who covers the manager’s seat for the duration of the case.

How should an incident that starts out of hours be handled?

Use the same first-hour decisions and the same log. What changes is who is reachable. Agree in advance which decisions the on-call manager can make alone and which need a call to the executive sponsor, so nobody has to improvise the escalation at night.

For the escalation side, see the escalation criteria and support handoff post.