ServiceNow Security Operations Best Practices

Security operations is the daily work of watching security alerts, deciding which of them are real, and responding in proportion to the threat. This page sets out how to triage, investigate, escalate and learn from each case, and the routines that keep the queue honest.

Establish a Clear Alert Triage Process

Security tools generate thousands of alerts daily. Without a triage process, alerts pile up and high-severity issues are buried in noise. Triage is the first step: evaluate each alert to decide whether it represents a real threat or false positive.

Good practice is to define triage rules in configuration: alerts from certain sources are automatically high-priority. Alerts that match known false positive patterns are automatically closed. Alerts from medium-risk sources are routed to a specific team. This automation reduces manual work and ensures consistent handling.

A triage workflow should capture: what the alert is, where it came from, what action was triggered, and a human decision: is this a real security event or noise? Once triaged, legitimate alerts move to investigation; false positives are closed with a reason recorded.

The triage team should be trained to recognise patterns. After three weeks of operation, review triage decisions: which types of alerts keep coming in and being marked false positive? Update the triage rules to eliminate them automatically. This reduces triage work and frees the team to focus on real threats.

Design Investigation Workflows Based on Alert Type

Not all investigations are the same. A suspicious login from an unusual location requires different investigation than a malware detection. Design separate investigation workflows for different threat types.

A workflow for suspicious login might include: check the user’s recent activity, compare to baseline access patterns, contact the user to confirm they made the login, and take action if it was unauthorised (force password reset, revoke sessions). A malware detection workflow might include: isolate the affected system, scan for additional compromises, review recent file changes, and restore from backup if needed.

Each workflow should include decision points: does this look like a real threat or a false positive? If real, what is the severity and what is the appropriate response? The workflow should auto-escalate if severity is high.

Workflows should also track ownership: who is responsible for each step? If a step is not completed within a time window, escalate to a supervisor. Do not assume someone is working on an investigation; make accountability explicit.

Implement Tiered Response Actions

Response actions must be proportional to threat severity. A suspicious login might warrant a password reset. A confirmed malware infection might require system isolation. A suspected data exfiltration requires investigation and escalation to leadership.

Define response actions by severity tier: Low severity (false positive likely, monitor) → action is none, close alert. Medium severity (suspicious but not confirmed) → action is contact user, review logs, reset password if needed. High severity (confirmed threat) → action is isolate system, revoke access, begin forensic investigation. Critical severity (active attack, data loss possible) → action is emergency escalation, take system offline, notify leadership.

Automating low-severity responses saves time. For high-severity responses, require human approval before taking action (e.g., before isolating a critical system). This balances speed with safety.

Link Alerts to Known Threats and TTPs

Security Intelligence feeds provide information about known adversaries, their tactics (TTPs), and recent attacks. When an alert comes in, check whether it matches any known TTP. If it does, the threat is more credible and the response should be faster.

Configure the system to correlate alerts with threat intelligence: if an alert shows a connection to an IP address flagged as malicious, that correlation should be visible. If an alert matches a known TTP for a specific adversary, that context should be in the investigation record.

This requires integration to threat intelligence feeds (vendor feeds, industry ISACs, internal threat intel from past incidents). Keep feeds up to date; stale threat intel is worse than no intel because it creates false confidence.

Use Playbooks to Automate Repetitive Investigation Steps

Playbooks are sequences of automated actions that gather evidence without human intervention. A playbook can pull logs from multiple systems, query the endpoint for recent activity, and assemble findings in a single view.

Example playbook: User login from unusual location detected. Playbook runs: pull user’s login history for the past 30 days, check if the IP is in a known corporate range, check if the location matches the user’s usual pattern, query Active Directory for recent group changes on this user’s account. Results are presented to the investigator with recommendations: “High confidence unauthorised access” or “Likely legitimate travel-related login”.

Playbooks save hours of manual investigation time. They should be kept simple and focused: one playbook per alert type. Complex playbooks that try to handle all scenarios become hard to maintain.

Track Investigations to Closure and Learn From Them

Every investigation should have an outcome: false positive (no threat), threat remediated, threat ongoing (escalated), or threat contained (system isolated, awaiting review). Track this outcome in the system.

After the investigation, ask: what did we learn? If a sophisticated attack slipped past detection for days, why? If a playbook gave false positives, how should it be tuned? Create improvement stories based on investigation outcomes. This turns reactive defence into proactive refinement.

A review cadence helps: monthly, summarise investigations by type. Which types do we see most? Are response times improving? Which investigations are taking too long? Use this data to adjust priorities, improve training or improve automation.

Maintain Escalation Paths to Leadership

Some investigations uncover threats that require immediate action beyond the security team’s authority: take a system offline, shut down a customer account, or notify law enforcement. Define escalation paths.

Escalation should be automatic for severe threats: if malware is spreading or data is being exfiltrated, the CISO and incident commander are notified immediately. Thresholds should be clear: “If 10 systems are infected, escalate. If data loss is suspected, escalate. If the threat came from a specific adversary, escalate.” Do not wait for a security team member to decide.

Escalation paths should include: who is contacted first (team lead, manager, CISO), when they are contacted, what information they receive, and what decision or action they are expected to take. Do not escalate and then leave leadership hanging; provide context and options.

Operating rhythm: the routines that keep a security queue honest

A security operations function is shaped less by its tools than by the routines around them. Who picks up the queue at the start of a shift, how the previous shift hands over open work, what happens to alerts that arrive while the team is small, and how near misses get recorded all decide whether a real signal survives the day. The practices below are routines rather than features, and most of them cost little beyond discipline, which is why they are often the first to slip.

This section is for the duty lead and the operations manager who set the rhythm of the team. It is not a replacement for the triage and escalation practices described elsewhere in the library. It covers the daily and weekly habits that make those practices hold up when the team is busy or short-staffed.

Practices, what they protect against, and the sign that one is missing

A start-of-shift sequence for each shift

1. Read the handover and confirm each open incident has a named owner. Any incident without one is assigned before anything else.
2. Check that every expected source has delivered events since the last shift. A source that has gone silent is treated as an incident of its own until it is explained.
3. Review the watch list for indicators or assets flagged by the previous shift, and decide which need active checks this shift.
4. Confirm who is covering escalation and how they can be reached, including the route for anything that must reach a manager out of hours.
5. Write one line in the handover log stating that the checks were done, and any problem found.

The near-miss log is often a low-cost improvement

A near miss is an event where a control worked by chance, or where a gap was noticed before it was exploited. Recording these is valuable because the lessons come at little cost: nothing was lost, so there is no blame to manage and no incident report to write. Keep the entry short, covering what was seen, why it was not decisive, and the one change that would make it decisive next time. Review the log monthly and ask which entries describe the same weakness. Repeated entries can be a signal that a fix is overdue.

Quiet periods and single points of knowledge

Many teams have one analyst who knows how a particular integration behaves or why a rule exists. That knowledge is an operational risk. Make the knowledge explicit by asking the person to write a short note on each integration and rule they own, then have a second person run through one of them while the owner is present. Keep the notes next to the rules in the record, not in a personal document. The test of the practice is simple: if the owner were away for a week, could a capable colleague explain what the rule does?

Where habits break down

Routines can fail in two predictable places. The first is the busy period, when the handover and the first-hour check are the first things dropped. Agree in advance which checks are non-negotiable even when the queue is heavy, and make the rest optional. The second is a change of leadership, when new managers may judge the rhythm as overhead. Explain the purpose of each routine before removing it, and remove it only if the failure it protects against is no longer possible.

Do the handover and the first-hour check need to be documented in the platform?

The handover should be in the record so it survives a change of staff. The first-hour check can be a short standard list, but its results should be written where the next reader will see them.

How do we keep the weekly alert-type review from becoming a meeting nobody attends?

Make it a single page with three numbers and two questions, owned by one person. If it cannot be read in ten minutes, it is too long.

Should near misses be shared outside the security team?

Share the lesson, not the incident detail. Other teams often own the control that failed, and a clear explanation of the weakness helps them act without needing the full record.

What if analysts resist the handover format?

Ask them what the last handover got wrong. Resistance often comes from handovers that were never read. A short handover that people actually read beats a thorough one that sits unopened.

Turning these routines into a standard

Once the rhythm is working, write it down as a team standard so it survives the next change in staffing. Record each routine’s owner in the roles, responsibilities and RACI guide; the adoption and training plan covers how newcomers are brought into the team.