Looking for real-world SIR implementation lessons learned

[Aebalo]

Hi everyone,

I’m looking to connect with practitioners who have implemented or currently support Security Incident Response (SIR), especially in public-sector or large-enterprise environments.

I’m looking to better understand the real-world experience with SIR beyond product demos and documentation.

A few things I’d especially like to learn:

• What use case did you start with, and would you start there again?
• Where has SIR worked particularly well for your organization?
• Where did you run into gaps or have to adjust your process?
• How do you handle intake from teams outside of Security?
• What integrations have been most important to your implementation?
• If you were starting your SIR implementation again today, what would you do differently?

I’d also appreciate any recorded customer presentations, implementation examples, public-sector use cases, or other Community resources that demonstrate SIR operating in real-world environments.

Happy to trade lessons learned as well. I’m currently doing quite a bit of work around ITSM, CMDB, CSDM, and enterprise ServiceNow governance.

Practitioner/customer perspectives only, please. No vendor or partner outreach on this one.

Thanks in advance.  I’d appreciate any experiences, lessons learned, or resources the Community can share.

[Aravind2799]

Hi! I've been hands-on with SIR on a public-sector implementation (SIEM-driven, multiple incident categories, downstream handoffs to other ticketing systems), so here's what I've learned, with no pitch attached.

What use case did you start with, and would you start there again?

We started with SIEM-generated alerts (Splunk ES notables) feeding SIR, and I'd start there again, but with one or two incident categories rather than all of them at once. User-reported phishing is the other strong first candidate: it's high volume, well understood, and shows value quickly. Getting one category working end to end (intake → triage → containment → closure → reporting) teaches you more than any amount of design workshops.

Where has SIR worked well?

• One auditable record of the incident lifecycle. That matters a lot in public sector, where reporting obligations and after-action reviews are formal.
• Playbooks enforce consistency across analysts and shifts.
• CMDB and ownership data are already on the platform, so analysts can see what's affected and who owns it without pivoting to other tools.

Where did you run into gaps?

• CMDB quality is the biggest dependency. If configuration items aren't matched reliably, business impact and assignment both fall apart.
• Alert volume and deduplication. Decide early which events become security incidents and which stay as alerts. Otherwise the queue floods and analysts lose trust in it.
• Field mapping to the SIEM needed more iteration than expected, especially severity and category normalization.
• Data visibility. Security records need tighter access controls than ITSM. Plan roles and ACLs deliberately, particularly when other teams need partial visibility.
• Downstream handoffs to non-ServiceNow systems need clear ownership of status sync. Decide which system is the source of truth for each field.

How do you handle intake from outside Security?

• Employees report through a catalog item or portal form.
• Service desk agents can escalate a regular incident into a security incident, which keeps sensitive details out of the ITSM record.
• A monitored mailbox with inbound parsing for some teams.

The key is a lightweight form for reporters and a restricted record for analysts, so non-security staff never see more than they need to.

Which integrations mattered most?

SIEM first, by far. After that, in rough priority: email (phishing intake), EDR for containment actions, threat intel enrichment, identity directory lookups, and Vulnerability Response for linking incidents to known exposures.

What would you do differently?

• Run a CMDB readiness check before go-live.
• Define severity and escalation criteria with the SOC and leadership before building anything.
• Keep playbooks simple in phase one, then add automation once you trust the data.
• Involve the people who own your reporting obligations early. Post-incident reporting requirements shape the data model more than you'd expect.

Resources

The SIR implementation material on Now Learning and the Security Operations product docs are good for the baseline. Past Knowledge conference sessions on SecOps (searchable on Now on Demand) include some customer-led talks.

Happy to compare notes on how CSDM decisions affect SIR's business impact calculations, since that's where your current work and SIR overlap most.
Thanks 
Aravind Panchanathan

[Cheryl ODell]

Hello,

Our Healthcare organization implemented SIR 4 years ago.  I've been the admin of our SIR environment for the entire time.

• What use case did you start with, and would you start there again?
• We were dealing with a lot of user and device compromises, so that is where we started with our playbooks.  User compromises from phishing and vishing.  We needed to create investigations to keep details private and to have some metrics.  Yes, I think we would at that time.  Now that our security program is a little more mature, I think I would focus on linking with our SIEM to keep the SOC analysts engaged with the SIR platform.
•  
• Where has SIR worked particularly well for your organization?
• In managing our alerts from ISACs to help us denote IoCs into our firewalls and EDR integrations.  We also developed Runbooks and workflows to help automate what we could and provided step by step instructions on how to handle the event based on the category.  However, once everyone knew the steps by heart, the tasks in the workflow became a hinderance because they had close each task to close the incident.
•  
• Where did you run into gaps or have to adjust your process?
• Our SOC Manager has changed to 4 different people in the last 4 years; and not every SOC Manager would adhere to keeping everything in SIR.
•  
• How do you handle intake from teams outside of Security?
• Our service desk has access to the button 'Create Security Incident' so it would link the INC and the SIR ticket; however, any worknotes added to the SIR ticket do not get added to INC ticket (which is good) but when we close a SIR ticket, it closes the INC ticket.  That's not good for device compromises where the investigation is completed and the technical teams are reimaging/reloading devices.

• What integrations have been most important to your implementation?
• Palo Alto firewall integration, VirusTotal integration, Splunk Integration
•  
• If you were starting your SIR implementation again today, what would you do differently?
• To understand the capabilities of SIR, and not just rely on the implementer or the sales pitch our CISO received.  There are a lot of decisions and we wanted to stay as close to as OOTB as possible.  However, the implementer was helping us to setup SIR to do exactly how we did things - which we were willing to change to best practices.  I didn't receive any training about SIR, and I wasn't even in the know of what we purchased - which eventually became an issue.  We were paying for things we either decided in the end we would not need, etc.  And, I would make sure you have the SOC manager and maybe even a SOC member to be involved to help make the decision points - or create a SIR governance group to make those decisions that include representation from CISO, other InfoSec leadership/managers as well as the SOC members.  We relied too heavily on our implementer making decisions for us thinking they were leading us into best practices.  We just didn't have the right people engaged during implementation.

Hope this helps.  

Cheryl