ServiceNow Security Incident Assignment Rules and Security Incident Response Task Assignment

Why every security incident lands in the SIRT group

Most teams discover this when they create their first tiered groups. A new security incident is submitted with the assignment group empty, and on save it shows SIRT. A user asked exactly that in the ServiceNow secops forum: whenever a security incident is submitted it picks SIRT as the assignment group, and he wanted it to go to a new group called Security Tier 1 instead. A second user had the opposite complaint. He had set the assignment option to manual and still saw SIRT populated on every new record.

A ServiceNow employee gave the same answer in both threads. There is an assignment rule on the sn_si_incident table called SIRT Assignment, and that rule is what puts the group there. The fix is to set that rule to Active false and create your own assignment rule for the default group you actually want, using the baseline rule as a reference.

The detail worth understanding is why the manual setting did not help. The assignment method on the Security Incident Response configuration screen decides how an analyst is chosen. The SIRT Assignment rule is an ordinary platform assignment rule, under System Policy, Rules, Assignment, and platform assignment rules fill an empty assignment group on insert regardless of what the SIR configuration says. Two settings, two owners, and nothing on either screen mentions the other.

Once you deactivate it, write your replacement rules carefully. Platform assignment rules only act on records that do not already have an assignment, so a rule never overrides a group set by an integration, a playbook or a person. If your SIEM integration already writes a group, the rules never see the incident at all.

The four ways SIR can choose the analyst

The Assignment tab of the Security Incident Response configuration screen offers four approaches, and the documentation describes each one in a sentence.

• Manually. Security analysts are assigned by hand whenever someone or the SIR application creates a security incident or generates a security response task. ServiceNow positions this for teams with few analysts.
• Using a workflow. A selected workflow assigns the analyst whenever an incident or response task is created, so the logic lives wherever the workflow lives.
• Using auto-assignment. The platform scores analysts against criteria you choose and assigns the highest score.
• Advanced Work Assignment. AWA automatically assigns security incidents to analysts based on their availability, capacity and, optionally, skills, through service channels and queues.

Each one is a reasonable choice for a certain team size, and each fails in a predictable way. Manual depends on someone watching the queue, which is precisely what does not happen at 3 in the morning. A workflow is invisible logic that nobody wants to touch two years later. Auto-assignment is precise about geography and skills and silent about load. AWA is closest to a real routing engine, but it brings presence, capacity and service channel configuration that a small SOC rarely maintains well.

How SIR auto-assignment scores analysts

Auto-assignment is the option most teams pick first, because it looks like intelligent routing. ServiceNow documents four selection criteria, each producing a rating from 0 to 1 for every eligible analyst.

• Location. Analysts are rated on the distance between the home location in their user record and the location of the task. The closest analyst rates 1, and the rating falls to 0 beyond 100 miles.
• Skills. The rating is the share of the required skills the analyst holds, Skills_agent divided by Skills_task.
• Time zone. The rating is 1 minus the absolute difference between the task time zone and the analyst time zone divided by 12. An analyst twelve hours away rates 0.
• Group coverage areas. Analysts are matched on the coverage area defined in their user records.

You give each criterion a priority from 1, less important, to 10, important, and the final score is the sum of each rating multiplied by its weight. The analyst with the highest score gets the incident.

Read that list again and notice what is missing. There is no criterion for how many security incidents or response tasks an analyst already has open. The analyst in the right city, with the right skills, in the right time zone wins every time, including the eleventh time that morning. A SOC that sets location and time zone heavily, which is the common setup for a follow the sun team, concentrates work on whoever sits closest to where the incidents are reported.

Skills have a harder edge. ServiceNow states that if no agents possess all the skills required to perform the task, no one is auto-assigned. Add a rare skill to a category of incident, malware reverse engineering for example, and every incident in that category arrives with a group and no analyst. Nothing errors and nothing alerts. The incident simply waits.

Advanced Work Assignment for security incidents

AWA moves security incident assignment closer to a contact center model. Analysts need the sn_si.analyst and awa_agent roles, work arrives in the Inbox of the Security Incident Response Workspace, and whether an analyst gets an incident depends on the configured service channel, queues and assignment rules, plus their presence.

Presence has three states. Available means the analyst can accept security incidents, Away means they are not available for new assignments, and Offline is the default. That default matters more than it sounds. On a quiet morning nobody opens the inbox and changes status, so new incidents queue and AWA assigns nothing. The incident is routed but not owned.

If auto-assignment is on in AWA, incidents are assigned to the analyst directly. Otherwise they are offered and the analyst accepts. An analyst can reject with a reason only if rejection handling has been enabled; without it the Reject option is not shown. AWA measures capacity in work items, not in effort, so a containment incident with forty hours of work and a closed false positive weigh the same.

AWA is a strong choice for a large SOC with defined channels and disciplined presence. For a five to fifteen person security team it is often more configuration than the team will maintain, which is why so many instances run auto-assignment or plain manual pickup instead.

Security incident response tasks and post incident reviews

A security incident is rarely one record. Playbooks and analysts create security response tasks for containment, evidence collection, user notification and remediation, and the assignment method on the configuration screen applies to those tasks as well as to the incident. If your method leaves incidents with a group and no analyst, it leaves every generated task the same way, multiplied by the number of tasks in the playbook.

The common symptom is a closed or stalled incident with two or three tasks still sitting in a group queue. The incident owner assumed the network team would pick up the firewall block; the network team assumed the task was informational. Nobody was named.

Post incident reviews have their own assignment rules, under Security Incident, Administration, Post Incident Review, Assessments Setup, in the User Assignment Rules section. Each rule has an order, a condition on the security incident, assignment options for users, roles or email addresses, and an optional assignment group, in which case all active members of the group with the sn_si.analyst role are added to the review. ServiceNow notes that only the first matching assignment rule is executed, so a broad rule with a low order number silently shadows every specific rule below it. That is the same first match pattern that causes problems in Vulnerability Response assignment rules.

A practical setup that keeps security incidents owned

The structure that holds up is the same whatever method a team started on.

1. Deactivate SIRT Assignment and write explicit group rules. One rule per category or region, each with a unique order, and a catch all rule at the highest order that points at a triage group someone actually watches.
2. Keep skills short. Require only the skills an incident cannot be worked without. Put nice to have skills in the weighting, not in the required list, so an incident is never left with nobody qualified.
3. Decide where load is counted. Auto-assignment does not count it and AWA counts items, not effort. If fairness matters, something has to count open incidents and tasks per analyst and weight critical work higher.
4. Respect shifts. Time zone scoring is not a schedule. An analyst inside the right time zone who is off shift still scores well.
5. Assign tasks, not just incidents. Every response task should have a named owner when it is created, from the same rules.
6. Record the reason. When the CISO asks why a critical waited, you want the rule, the load and the availability at that moment, not a guess.

Points three to six are where a native configuration gets expensive, either in custom script or in AWA administration. That is the part Assigner is built for.

How Assigner assigns security incidents beside ServiceNow

Assigner sits beside your ServiceNow instance and decides who gets each security incident and response task. ServiceNow keeps the incident, the playbook, the evidence and the audit trail. Assigner reads the new record, applies your rules and writes the assignment group and assigned analyst back.

• Load counted the way your SOC counts it. Open security incidents and response tasks per analyst, with critical and high severity weighted heavier, so the analyst with four open criticals is not next in line.
• Skills without dead ends. Required skills narrow the group; if nobody available holds them, the incident escalates to a named fallback instead of waiting unassigned.
• Shifts and out of office. Analysts off shift or out are skipped, which time zone scoring alone cannot do.
• One rule set for incidents and tasks. Response tasks get an owner the moment the playbook creates them.
• A reason on every assignment. Each one records the rule, the load and the availability behind it, for example skill match, lowest open load and on shift.

Pricing is per user: Starter at $7 per user per month billed yearly, with load balancing on Team at $18 and advanced rules on Business at $36, all billed yearly, from 5 users. Assigner does not replace Security Incident Response, playbooks or threat intelligence, and it does not guarantee response times. It makes sure every security incident has one accountable analyst, and that you can say why.

What are security incident assignment rules in ServiceNow?

They are platform assignment rules on the sn_si_incident table that set the assignment group when a security incident is created without one. The baseline rule is called SIRT Assignment and sets the SIRT group. Post incident reviews have their own separate user assignment rules under Assessments Setup.

Why are security incidents automatically assigned to the SIRT group?

Because of the baseline assignment rule SIRT Assignment on sn_si_incident. A ServiceNow employee confirmed it in the secops forum. Set that rule to Active false and create your own assignment rule for the default group you want, using the baseline rule as a reference.

How do I stop ServiceNow from auto-assigning security incidents?

Set the assignment method on the Assignment tab of the Security Incident Response configuration to manual, and also deactivate the SIRT Assignment rule. The manual setting controls how analysts are chosen; the rule still fills the group until it is turned off.

How does Security Incident Response auto-assignment choose an analyst?

It rates each analyst from 0 to 1 on the criteria you enable: location, skills, time zone and group coverage area. Each criterion gets a priority from 1 to 10, the weighted ratings are added up, and the highest score wins. Open workload is not one of the criteria.

Why is a security incident not assigned to anyone?

The most common causes are a required skill nobody holds, since ServiceNow assigns no one when no analyst has all required skills, analysts set to Offline in AWA, which is the default, and a group set by an integration or person before any assignment rule could run.

Can Advanced Work Assignment assign security incidents?

Yes. AWA assigns security incidents based on availability, capacity and optionally skills, using service channels, queues and assignment rules. Analysts need the sn_si.analyst and awa_agent roles and must be Available in the Security Incident Response Workspace inbox to receive work.

How are security response tasks assigned in ServiceNow?

By the same assignment method set on the Security Incident Response configuration screen, which applies when someone or the application generates a security response task. Tasks therefore inherit the same gaps as incidents, and playbook tasks often sit in a group with no analyst.

What roles does a security incident assignment group need?

ServiceNow guidance is to add sn_si.analyst to the Roles related list of a group for Security Incident Response team members and sn_si.admin for administrators. Users with user_admin can create the groups; sn_si.admin can create and edit security incident assignment groups.

Does ServiceNow security incident auto-assignment balance workload?

Not with the documented criteria. Location, skills, time zone and coverage area say nothing about how many incidents an analyst already holds. AWA counts capacity in work items. Weighting by severity or effort needs custom logic or a routing layer such as Assigner.

How do post incident review assignment rules work?

Each rule has an order, a condition on the security incident, users, roles or emails to add, and an optional assignment group whose active sn_si.analyst members are added. Only the first matching rule runs, so order specific rules before broad ones.

Can I assign security incidents round robin in ServiceNow?

Not with the SIR auto-assignment criteria, which score fit rather than rotate. AWA can approximate rotation through its assignment rules, or you can script it. Assigner offers round robin, weighted round robin and load balanced assignment beside ServiceNow.

How much does Assigner cost for a SOC team?

Starter is $7 per user per month billed yearly, Team with load balancing is $18 and Business with advanced rules is $36, all billed yearly with a 5 user minimum. You license the analysts who receive work, not every employee in the instance.