Meaningful SLAs for ServiceNow SIR

Designing Practical SLAs for ServiceNow Security Incident Response 

ServiceNow Security Incident Response (SIR) provides the incident lifecycle, but defining useful SLAs still requires an important design decision: what exactly should start and stop the clock?

For a PoC implementation, I configured two sequential SLAs on the Security Incident [sn_si_incident] table:

Both use the Default SLA flow and run 24×7 by using no schedule.

Initial Response SLA

The first SLA measures how long a Security Incident remains in its initial Draft stage before analysis begins.

Draft ───── Initial Response SLA ─────► Analysis

                               ≤ 1 hour

Using State = Analysis as the stop condition is intentional. It represents a specific business milestone rather than simply stopping whenever the incident leaves Draft.

Investigation SLA

Once the incident enters Analysis, the second SLA starts:

Analysis ───── Investigation SLA ─────► Next state

                                    ≤ 4 hours

Its current stop condition is State != Analysis, meaning it measures how long the incident remains in the Analysis phase.

This also creates a clean SLA chain:

Draft ─────────► Analysis ─────────────► Next phase

         Initial Response                   Investigation SLA

           ≤ 1h                                      ≤ 4h

Testing confirmed this behavior. When a Security Incident was moved from Draft to Analysis, the Initial Response SLA completed and the Investigation SLA immediately started.

Stop versus Cancel

A useful distinction in SLA design is between completing and cancelling an SLA. Reaching the intended lifecycle milestone should complete the SLA. Abandoning the process should cancel it. Therefore, both definitions use:

Cancel condition: State = Cancelled

24×7 or Business Hours?

These SLAs use No schedule, so ServiceNow measures continuous elapsed time.

For a 24×7 security operation, this is generally more meaningful than a business-hours schedule. If the organization only provides security response during staffed hours, however, an appropriate SLA schedule should be configured instead.

Key Design Principle

The most important lesson is to design the measurement before configuring the SLA:

Define the time between business milestone X and business milestone Y, then translate those milestones into ServiceNow conditions.

For SIR, state transitions provide a simple way to do this:

Business requirement

        ↓

SIR lifecycle milestone

        ↓

Start / Stop / Cancel conditions

        ↓

Task SLA

Avoid adding complexity unless the process actually requires it. Two well-defined SLAs with clear lifecycle boundaries can provide more useful operational measurements than a large collection of overlapping SLA definitions.

For any SIR SLA, I would validate three things before considering it complete: the normal lifecycle transition, cancellation behavior, and an actual breach.

That's a wrap!