ServiceNow Major Incident Management Governance Model

Decision Forums and Response Structure

A Major Incident Command Center is the decision forum for active major incidents, bringing together IT operations, service delivery and business stakeholders to coordinate response. This forum convenes when a major incident is declared and operates until the incident is resolved and a post-incident review is completed. Frequency and attendees depend on severity: critical incidents may convene continuously; serious incidents might meet at a set interval. An Incident Manager leads the forum, facilitated by a communications coordinator who manages notifications and status updates to stakeholders.

Strategic Review and Governance

A Major Incident Review Board convenes weekly or monthly to review completed major incidents and approve changes to incident management processes, standards and tooling. This forum involves senior IT leadership, process owners and subject matter experts from key IT domains. They review post-incident reports and recommend process changes to prevent recurrence.

Standards and Procedures

Define criteria for declaring a major incident: any incident affecting a large number of users, any incident affecting a critical business system for an extended period, or any incident causing financial loss. Document the escalation trigger point and who has authority to declare a major incident. Establish a communication template so stakeholders receive consistent, timely updates. Define roles: who is the Incident Manager, who manages technical response, who manages customer communication and who provides executive updates. Specify how long an incident command center remains active and what triggers the transition to normal support processes.

Change Control During Major Incidents

When a major incident response requires a configuration change to the production platform, that change must follow your standard change control process unless an emergency change procedure is explicitly invoked. An emergency change procedure allows selected individuals to make urgent changes under defined conditions, such as during an active major incident affecting business operations. The emergency change must be logged, approved by an authorized change approval board member and reviewed after the incident is resolved. Configuration changes made during a major incident should be treated as temporary workarounds initially, then formally reviewed and refined for permanent deployment after the incident is closed.

Ownership and Escalation Paths

Assign ownership of the Major Incident Management program to an individual or small team, typically the Service Delivery Manager or Incident Manager. They own the major incident checklist, communication templates, training and post-incident review process. They are accountable for ensuring that major incidents are declared when appropriate and that command center procedures are followed. Escalation path: if an Incident Manager cannot declare a major incident or needs emergency change approval, escalation goes to the IT Operations Manager or Service Delivery Director. If a major incident persists longer than expected, escalate to the IT Director for resource or strategic decisions.

Review Cycle and Continuous Improvement

Every major incident triggers a post-incident review, conducted soon after incident resolution while details are fresh. The review examines the timeline, what worked well, what could be improved and any configuration or process changes needed. Results are documented and shared at the Major Incident Review Board meeting. The board reviews trends across multiple incidents to identify systemic issues: for example, if several major incidents involve the same system, the board may recommend architectural changes or additional monitoring. Annually, review the major incident definition and thresholds to confirm they remain appropriate.

Communication Templates and Stakeholder Notification

Develop communication templates for major incident declaration, status updates and closure. A template should include what happened, who is affected, when recovery is expected and what the incident team is doing. When a major incident is declared, the communications coordinator sends the template to all stakeholders (customers, business leadership, impacted teams). Templates reduce the time needed to craft messages and ensure consistency. As the incident evolves, update the template with latest information and resend. After closure, send a final communication summarizing what was learned and what is being done to prevent recurrence.

Document escalation outcomes: what was decided, who made the decision, what actions were taken. This information helps identify patterns and improve the escalation process over time. Escalation tracking should include resolution time, resources deployed, and customer impact. Track patterns in escalation to improve the decision-making process for future incidents. If certain escalations consistently reach the IT Director, that may indicate a need for clearer decision authority at lower levels.

Metrics and Performance Tracking

Track key metrics for major incident management: mean time to detection (how quickly is a major incident recognized), mean time to declaration (how long between detection and formal declaration), mean time to resolution (total duration of the incident), and mean time to restoration (how long until normal operations resume). These metrics reveal whether your governance model is functioning effectively. If mean time to declaration is increasing, that suggests decision criteria are unclear or authorities are hesitant. If mean time to resolution is stable but customer impact is growing, that suggests impact criteria need adjustment. Review these metrics monthly at the Major Incident Review Board to identify trends and resource constraints.

Choosing who owns the governance rules

Every major incident model needs someone who can change the rules between incidents, and the question of who that is shapes everything else. Governance fails in two directions. Rules that one person changes on their own drift away from what responders actually do, and rules that a committee changes slowly never catch up with the last incident. The table below compares the three ownership patterns that tend to work in practice. None is correct everywhere; the right one depends on how many teams share the service and how often a major incident happens.

Setting decision rights as a set of six decisions

Many governance documents describe roles in general terms. What responders need is a short list of specific decisions, each with a named decider, the evidence the decider must have, and a place where the decision is recorded. Agree these six before the next declaration, and write them into the major incident record template so they are not a separate document nobody opens. The people who hold each role are described in the roles, responsibilities and RACI guide, which pairs naturally with this table.

The separation between the commander who makes a decision and the approver of an emergency change is often the part that gets collapsed. When one person does both, the control that the governance model is meant to provide disappears at exactly the point it is needed.

Amending the governance rules without losing track of them

1. Write the proposed change as the new wording of the rule, not as a description of the problem it solves.
2. Attach the incidents where the current rule caused a delay or an unclear decision, using the record references.
3. Name the owner who will approve the change and the date from which it applies to new declarations only.
4. Update the template and the decision table in the same change, so the written rule and the configured rule do not diverge.
5. Announce the change to the people who make the decisions, with the one paragraph that tells them what is different.
6. Check the next two declarations against the new rule and record whether it helped, which feeds the metrics that show whether governance is working.

Where governance drifts after the first year

• The decision table stays in the design document while responders use a verbal rule they learned from the last incident.
• Thresholds are kept from the original design even after the services they describe were rebuilt or retired.
• Emergency change approvals begin to arrive from the same person every time, which turns a control into a formality.
• The review of closed incidents is scheduled but moved each month until it stops, and the change log stops growing with it.
• New business units join the bridge without being added to the decision table, so their people have no defined authority.

When a lighter structure is the right answer

A small organization with one operations team and a handful of services may not need a standing review panel at all, and the handoff rules from standard support can be kept as they are, as described in the escalation criteria for support handoff. In that setting, the program owner can hold the change log, the incident commander can run the six decisions from memory, and the written rules can be a single page. Building a panel, a quorum and a formal amendment cycle for that setup adds overhead without adding control. Add structure when the number of teams making declarations grows, not before.

Follow-on questions about governance in use

Should the governance rules be published to every employee?

Publish the parts that people act on: the declaration test, the decision table and the escalation path. The change log, the review minutes and the reasoning behind thresholds can stay with the program owner and the review group, since most staff only need to know what to do and who to call.

Can an incident commander depart from a written rule?

Only where the rule itself allows a deviation, and the deviation is recorded with the reason and the time. The review that follows decides whether the rule should change or the deviation was a one-off. Undocumented departures are a common way a written model stops describing what people actually do.

Who keeps the change log current?

The program owner holds the log, but each entry should be written by the person who approved the change, on the day of approval. A log maintained entirely by one person after the fact can omit the changes that were made quickly under pressure, which are the ones most in need of a record.

Should standard incident handling sit under the same governance?

Share the vocabulary and the escalation handoff, but keep the decision rights separate. Standard incidents are resolved by the queue owners, and the major incident rules apply only once a declaration is made. Mixing the two makes it unclear who decides at the boundary, which is where many escalation delays begin.

Next step

The pattern that fits depends on your teams and services more than on the platform.