ServiceNow Security Operations: Roles, Responsibilities and RACI

Defining Security Operations Roles

Security operations centres (SOCs) coordinate detection, investigation, and response to security incidents. Key roles are: Security Operations Manager (owns the SOC, coordinates escalations, reports to leadership), Incident Handler (leads incident response, owns decision-making during response), Security Analyst (investigates alerts, collects evidence, supports handlers), and Threat Intelligence Analyst (tracks emerging threats, provides context for investigations).

In a smaller organisation, one person may hold multiple roles. In a large organisation, roles are highly specialised. Define role boundaries: who can approve an incident classification as a security breach, who can approve containment actions, who can approve evidence retention or deletion.

RACI Matrix for Security Incident Response

A RACI table clarifies decision authority and accountability. Here is a typical structure for security operations:

Alert Triage and Severity Assessment

Security analysts triage alerts: is this a true positive (a real security event) or a false positive (normal activity misclassified)? Analysts are responsible for the initial assessment and recommendation. Incident handlers review the analyst’s assessment and make the final severity and classification decision.

SOC managers are accountable for triage accuracy. If analysts consistently misclassify alerts (too many false positives, or missing real threats), the SOC manager is responsible for tuning the alerting rules or retraining the team.

Incident Handler Authority and Escalation

The incident handler leads the response to a confirmed incident. They have authority to: assign tasks to analysts, request data from system owners, approve containment actions (like disconnecting a system from the network). The handler is accountable for the incident outcome.

Handlers escalate to the SOC manager if the incident affects multiple systems, requires business unit approval for containment, or involves potential regulatory reporting. Managers escalate to leadership if the incident is a breach (confirmed unauthorised access) or affects customer data.

Evidence Collection and Chain of Custody

Security analysts are responsible for collecting and preserving evidence during investigations. This includes logs, memory dumps, network captures, and file copies. Analysts must follow a chain of custody: document who collected the evidence, when, how it was stored, and who accessed it.

The incident handler reviews the evidence for completeness and appropriateness. Forensic consultants or legal counsel may require evidence in a format that is court-admissible, so analysts need to know the standards upfront.

Containment and Recovery Decisions

Containment is a critical decision: disconnect the affected system (reducing risk but potentially losing evidence), kill suspicious processes (stopping the attack but affecting normal operations), or continue monitoring while gathering evidence (preserving data for forensics but allowing the attack to continue).

The incident handler owns this decision, consulting with analysts and system owners. The SOC manager is consulted if containment will significantly impact business operations.

Post-Incident Review and Metrics

After an incident is resolved, the team conducts a post-incident review: what happened, how did we detect it, how long did we take to respond, what should we do differently next time? Analysts contribute technical findings; handlers contribute process observations; the SOC manager identifies systemic issues and drives improvements.

Track metrics: mean time to detect (MTTD), mean time to respond (MTTR), false positive rate, incident volume by type. Use these metrics to prioritize tuning and training efforts.

On-Call Scheduling and Escalation

Define on-call rotations: who is on call 24/7, who escalates to during off-hours, who escalates to the SOC manager or leadership on weekends. Document response times: an analyst should triage an alert promptly after it arrives; a handler should assess severity within a window agreed with the SOC manager.

Use ServiceNow on-call management features to rotate schedules and track response SLAs. If a handler misses their SLA, alert the SOC manager for corrective action.

Where role boundaries fail in the first real incident

Many security operations teams can describe their roles on paper. The trouble shows up at about the third hour of a live event, when two people both believe they can authorize the same containment step, or when nobody is sure whether a case is still open for investigation or has moved to the post-incident stage. The RACI in a design document is a starting point, but it has to be tested against a timeline. Access rules that govern who sees each step are covered in security and access design. A useful exercise is to take a plausible scenario, such as a phishing campaign that has reached a handful of mailboxes, and walk each role through the decisions it would face hour by hour, noting where it would wait for someone else.

Two boundaries often cause much of the delay. The first is between classification and authority: an analyst may be able to label an alert as malicious but not be permitted to block an address that a business unit depends on. The second is between evidence and opinion: a handler may hold a strong view on root cause without a single preserved log to support it. Both boundaries need written rules, and the rules need to say what happens when the person who normally decides is unavailable. Communication during that gap is the subject of major incident communication.

A decision-rights table to agree before the next exercise

Ordered steps for turning the table into working rules

1. Pick two live decisions from the last quarter where the team hesitated, and mark who was asked and who answered.
2. For each decision, write the minimum evidence a person needs before acting. Keep it to what can be checked in the platform in under a minute.
3. Name a deputy for every role that can make a containment or closure decision. A deputy who has never handled a case is unlikely to be a useful deputy.
4. Store the rules in the platform’s own documentation or in the case template, so the person working the case sees them at the point of decision.
5. Run a tabletop exercise with one decision deliberately blocked, such as the handler being unreachable, and observe how the team routes around the gap.
6. Update the table after the exercise and record who approved the change and when.

Handover and the transition from triage to response

The moment a case moves from triage to response is where ownership often goes missing. The analyst who found the signal knows the context, the handler who takes over knows the procedure, and neither has written down what the other already knows. A handover note should carry the hypothesis, the evidence already preserved, the systems touched so far, and any action that was requested but not yet confirmed. Without those four items, the handler can repeat the investigation and the analyst assumes the response is in progress when it is not.

Shift changes need the same discipline. The thresholds that should trigger a handover are discussed in incident escalation criteria. A case open at the end of a shift should have a named owner for the next shift, a stated next action, and a time by which that action is expected. A case without those three things is still owned by whoever opened it, however tired that person is.

Patterns that look like good coverage but are not

• A single on-call handler who is also the only person allowed to approve containment. Coverage exists on the rota, but any leave turns it into a bottleneck.
• Threat intelligence analysts who receive every incident update. They end up forwarding information without being asked to contribute judgment, and the handler stops reading their messages.
• A manager listed as accountable for every metric without a defined trigger for when they step in. Accountability with no trigger is often reviewed only after a bad quarter.

Questions teams raise once the table exists

Can an analyst also be the handler on the same case?

Often yes on a small team, but the person who investigated should not be the only one who decides the case is closed. Where the same person does both, require a peer review of the closure note before the case leaves the active queue.

Who owns the metrics that come out of the incident review?

The security operations manager often does, because they are the person who can change staffing or tuning priorities. The security incident response RACI covers the parallel structure for response roles. The handler supplies the detail behind the numbers. Keeping the two roles distinct stops the review from becoming a debate about who made the mistake.

What if the legal team wants to be involved in every security case?

Ask legal to define the categories of case that need their involvement, such as possible personal data exposure or contractual notification duties. Involving them in every case can slow response and train people to route around the process.

Next step

A walkthrough using one of your real decisions can expose the gaps faster than another review of the matrix.