ServiceNow Security Incident Response: Roles, Responsibilities and RACI

Defining Incident Response Roles and Hierarchy

Security incident response involves cross-functional teams. Key roles are: Chief Information Security Officer (owns security, sets policy, reports to leadership), Incident Manager (coordinates the response, owns timeline and escalation), Technical Lead (investigates the incident, owns forensics), Communications Lead (manages internal and external communications), and Legal Counsel (advises on compliance and disclosure obligations).

In smaller organisations, one person may hold multiple roles. In large organisations, each role may have a team. Define role escalation: who fills in if the Incident Manager is unavailable? Who approves escalation to the CISO? Define decision authority: does the Incident Manager decide to isolate a system, or must they get approval from the Technical Lead?

RACI Matrix for Incident Response Activities

Detection and Initial Triage

The Incident Manager owns the overall incident timeline but is not necessarily the first person to detect the incident. Security tools, employees, customers, or external researchers may report a potential incident. The first responder (an analyst, engineer, or helpdesk agent) triages: is this a real incident or a false positive?

Once an incident is confirmed, the Incident Manager is activated and takes coordination authority. The Technical Lead investigates to understand scope and severity.

Containment and Isolation Decisions

Containment decisions are critical: isolate the affected system (stop the attack but potentially affect business), kill malicious processes (stop the attacker but lose evidence), or continue monitoring while gathering evidence (preserve data but allow the attack to continue).

The Technical Lead owns the technical decision, but the Incident Manager coordinates with business stakeholders if containment will impact operations. In some organisations, the CISO is consulted if containment is high-risk or high-impact.

Communications Strategy During Incident Response

The Communications Lead manages: internal updates (keeping leadership informed), employee updates (avoiding panic), customer communications (if customer data may be affected), media communications (if the incident becomes public), and regulatory notifications (if required by law).

Establish a communication cadence: update leadership at a regular interval during active response, notify customers promptly if their data is affected, and notify regulators within required timeframes, which vary by regulation.

Breach Assessment and Disclosure Obligations

Legal counsel advises on: whether the incident is a breach (unauthorised access to personal data), notification obligations (which regulators, customers, or employees must be notified), retention of evidence for potential litigation or law enforcement investigation.

The CISO or senior management makes the final decision on breach classification and disclosure. This decision must be documented and justified in case it is later questioned by regulators or customers.

Escalation and Decision Authority

Define escalation paths: if containment will cost more than a certain amount, escalate to CFO. If it will affect a critical customer, escalate to the customer’s account executive. If it will require law enforcement involvement, escalate to the CISO and legal.

Define escalation timelines: the Incident Manager makes a containment recommendation within an agreed time of incident confirmation; if approval is required, the decision must be made without delay to avoid extended exposure.

Post-Incident Review and Learning

After the incident is contained and systems are recovered, conduct a post-incident review: timeline of the incident, root cause, how it was detected, response effectiveness, and preventive actions.

The Technical Lead leads the investigation and writes the technical findings. The Incident Manager coordinates with other teams and identifies process improvements. The CISO uses the findings to guide security improvements (new controls, policy changes, training).

Incident Documentation and Evidence Retention

Document every incident response step: who did what, when, and why. Preserve evidence: logs, memory dumps, network traffic captures, screenshots. Archive this documentation in a secure location and retain it according to your legal and regulatory obligations (often several years).

If law enforcement is involved, they may restrict access to evidence for the duration of their investigation. Coordinate evidence retention with law enforcement and legal counsel.

Role coverage across shifts, leave and time zones

A role model that works at ten in the morning on a weekday can collapse at two in the morning on a holiday. The first design task is to show, for each role, who covers it on every shift and who covers it when the primary is on leave. Gaps in cover are normal and acceptable when they are visible and have a named fallback. What causes trouble is a gap nobody knew about.

Handing a live incident to a new incident manager

Changing the person who runs an active case can be one of the riskiest moments in a response. Context is lost, decisions are re-argued and the people on the call can hear the uncertainty. A written handover procedure can reduce much of that risk.

1. The outgoing manager writes a short status note in the work notes: current severity, open decisions, people on the call and the next scheduled update.
2. The incoming manager reads the decision log before joining the call, not after.
3. Both managers join one live call for a short overlap and confirm the owner of each open decision out loud.
4. The outgoing manager stays reachable for a defined period, and says so in the record.
5. The change of owner is recorded as a decision entry, so the timeline shows when accountability moved.

Writing role cards that people can actually use

A role card is a one-page statement of what a person in a role may decide, what they must hand on, and whom they inform. It can be more useful than a long RACI in the moment, because responders often do not read large tables under pressure. Each card should fit on one screen and be linked from the incident record.

• Decisions this role may take alone, written as plain verbs.
• Decisions this role may take only with a named approver.
• Information this role must send, to whom, and within what period.
• The condition under which this role hands the case to someone else.

When two roles pull in different directions

The technical lead wants to keep a compromised service running to watch the attacker. The communications lead has a customer who is already asking questions. Neither is wrong, and the incident manager has to decide. The role model should say in advance who breaks the tie, and what the default is when the tie cannot be broken in time. Many teams choose containment as the default, with a recorded exception when the business case for watching is strong enough.

Failures that role design can miss

• Two people believe they are the incident manager, and both send updates to different audiences.
• A deputy has never run a live case and freezes when called in.
• Legal is copied on every message, so their sign-off means nothing when a decision actually needs it.

Can one person hold two roles during an incident?

In a small team, yes, but the combination should be chosen deliberately. A technical lead who also acts as incident manager has a conflict when the investigation is slow and the case needs pressure applied. Record the combination in the role card so everyone knows it was chosen.

Who takes over at shift change?

The incoming person who holds the same role, following the handover steps above. If no equivalent role is on shift, the case stays with the outgoing owner until a named successor accepts it in the log.

How can deputies be named without weakening accountability?

Name the deputy as the person who acts only when the primary is unavailable, and keep the primary as the accountable owner in the record. The deputy’s name should appear in the handover note, not as a co-owner, so the question of who decided is always answerable.

What is the day-to-day role of legal in a live case?

Legal advises on which obligations apply and when, and approves the wording of any external message. Legal should not be the default owner of technical decisions, and the role card should say that in plain terms.

For how assignment groups support these roles inside the platform, the guide on assignment group governance is a useful companion, and the incident swarming coordination guide covers how specialists are brought together on one case.