ServiceNow Major Incident Management: Security and Access Design

Designing a Secure Role Model for Major Incident Management

Access design for Major Incident Management has to answer a narrow set of questions before the first declaration: who may declare, which responder roles hold which fixed access profile, how someone gets permissions they lack in the first minutes without widening access for everyone, and what trail that leaves. The sections below cover the role model, least privilege for responders, segregation of duties inside the workflow, audit evidence and the review cycle, post-incident access review, a break-glass procedure, and the signs that access has widened without a decision.

The incident commander role should have broad access to incident data, communications tools and status dashboards so they can coordinate response effectively. However, not everyone who can declare a major incident should have incident commander authority. Technical teams need access to investigate systems and data relevant to their part of the incident response. Security and audit teams need to understand what access was granted during the incident and why.

Implementing Least Privilege for Incident Access

Least privilege means staff have only the permissions necessary to perform their role during an incident, no more and no less. An incident responder investigating a database issue needs database access but may not need access to application configuration. A communicator updating stakeholders needs to create incident updates but should not have access to sensitive technical details about the issue.

The challenge is that incident response is time-critical and granting permissions during an active incident is dangerous. Most organizations pre-configure incident responder roles before incidents occur. During an incident, staff are assigned to predefined roles that already have appropriate permissions. This ensures response is fast without requiring security reviews during the crisis.

Temporary access elevation during incidents must be carefully controlled. Some scenarios may require someone to perform actions outside their normal role. Capture who requested access elevation, why it was needed and what actions they performed. This audit evidence supports post-incident review and prevents misuse of elevated access.

Segregation of Duties in Major Incident Workflows

Segregation of duties means different people should perform conflicting activities. The person who declares an incident should not be the only person who can access investigation data, preventing abuse. Someone should review major incident status updates for accuracy before they are sent to executives, preventing misinformation. When changes are implemented during incidents, someone independent should verify they were implemented correctly.

However, segregation of duties during an active major incident can slow response. Many organizations implement dynamic role assignment where needed segregations are built into the incident workflow. An incident commander cannot also be the approver for emergency changes. Technical teams who investigate the issue are separate from teams who implement fixes. Communications teams review status updates before distribution.

Audit Evidence and Review Cycle

Audit controls for major incidents capture who did what during the incident and why. These controls depend on ServiceNow logging and audit trails. Access logs show who accessed investigation data. Change logs show what was modified during incident response. Communication logs show what information was sent to stakeholders. This evidence supports post-incident review and security audits.

Establish a review cycle where major incident access and changes are examined periodically. Review access and changes soon after incident conclusion while events are fresh. This review confirms that access was appropriate, that segregation of duties was maintained and that no unauthorized changes occurred during the incident.

Some scenarios require emergency access that violates normal controls. These exceptions must be documented and reviewed. Emergency access should be temporary, limited to the minimum needed and justified by genuine incident circumstances. Using emergency access for routine work or without proper justification indicates broken controls that need attention.

Post-Incident Access and Change Review

After an incident is resolved, review and revoke any temporary access that was granted. Temporary database access for an incident responder should be removed when the incident concludes. Temporary firewall rules that were opened should be closed. Temporary user accounts created during an incident should be disabled. Leaving emergency access in place increases long-term security risk.

Changes implemented during major incidents should undergo review and approval even if they were implemented without formal change management during the emergency. Document what was changed, why it was necessary and verify that changes are stable and performing as intended. After incident response, transitions changes to normal change management for ongoing monitoring and support.

Matching each responder role to a fixed access profile

The access question during a major incident is rarely whether someone should be allowed in. It is which profile they should hold before the event starts, and which additional rights they may request while it is running. Designing those profiles in advance can remove much of the pressure that leads to over-granted access. The matrix that follows splits the rights one way. Adjust the columns to the actual platform roles in your instance, and keep the principle that the default profile is narrow.

A break-glass procedure that leaves a clear trail

Some events require rights that nobody holds in the normal profile. A break-glass procedure gives a defined route to those rights, with conditions that protect the control. Write it down before it is needed, and rehearse it once so the first real use does not improvise the steps.

1. The requester states the right needed, the reason and the record the right will apply to, in the incident timeline.
2. A named approver outside the requester’s chain confirms the reason and the time limit. Where no such approver is reachable, the procedure should say what the next option is, rather than leaving the requester to decide.
3. The grant is made for a fixed period tied to the record, and the expiry is recorded at the moment of grant.
4. Every action taken under the grant is traceable to the requester, using named accounts rather than shared logins.
5. At closure, the grant is revoked, and the revocation is checked rather than assumed.
6. The review examines the grant with the rest of the incident, including whether the right was really needed and whether the normal profile should be widened for next time.

What to do when a responder lacks access in the first minutes

A responder who cannot see the record they need will spend the first minutes trying to work around the gap, often by asking a colleague to forward screenshots or by copying data into a chat. Both approaches leak information and slow the response. The better route is a pre-agreed contact who can grant the defined profile or who can supply the data through a controlled channel, such as a read-only export that the commander has authorized. Name that contact in the procedure, and test that they are reachable out of hours.

Signs that access has been widened without a decision

• Responders from outside the rota appear on the record with write rights and no entry in the timeline explaining why.
• A shared account is used for a bridge session, and the audit trail shows several people acting under one name.
• Grants made during an event are still active weeks after closure, because revocation was never a named step.
• The same break-glass grant is requested for every event, which means the normal profile is too narrow and nobody has changed it.
• Security staff learn about a configuration change from a monitoring alert rather than from the response record.

Keeping the access model current between events

Profiles drift as people change roles and as services are added. The standard incident access design in the incident management security guide gives the baseline these profiles start from. A quarterly check that compares the people holding each responder profile with the current rota can catch much of the drift. Pair that check with a review of the break-glass log, since a grant that appears often is a signal the profile needs changing rather than a sign of a diligent team. Where a security event rather than an operational outage is in view, the triage steps in the security incident triage workflow should take precedence for containment, with this program handling coordination.

When a tighter model is not worth the effort

A very small team with one operations group and a short list of services may find that a written profile and a named approver are enough. Building break-glass tooling, separate integration accounts and quarterly attestation for that setting adds process without reducing real risk. The test is whether the team can explain, for each grant it made last year, who approved it and why. If it can, a lighter model is probably sufficient.

Questions about access during an event

Should the commander have approval rights for emergency changes?

Generally not. The role definitions that separate these duties are in the roles and RACI guide. The commander makes operational decisions under time pressure, and the approval of a change that the commander is directing should sit with someone else. Where the organization requires a single person to do both, the record should show the exception and the review should look at it.

Can a vendor’s support engineer be given a responder profile?

Yes, but through a separate account with its own expiry, its own scope and its own record of activity. Do not add vendor staff to the internal responder group, because that group carries rights the vendor does not need.

How should access for a bridge call be handled?

Give each participant an individual identity for the record and keep the call itself to the information the record already holds. Shared bridge credentials and screen sharing of unfiltered data are common ways that more access leaks out than the profiles intended.

Who revokes access if the incident runs for several days?

The commander holds the grants for the duration, and the handover note must name the holder of each active grant. Grants that outlive a handover without a name attached are a common reason access persists after closure.