ServiceNow Incident Management: Security and Access Design

Incident security and access design is the set of role rules that decides who can view, change and close an incident. It applies least privilege, so each role gets only what its job needs. It separates duties so the person who resolves an incident is not its only reviewer, and it logs significant changes as audit evidence.

Role Model and Least Privilege

A role model for Incident Management defines who can do what. Typical roles include Incident Reporter (can create and view their own incidents), Support Staff (can view and update incidents assigned to their group), Support Manager (can view all incidents in their scope, update incident priority or assignment), IT Security (can view all security-related incidents and tag them), and Compliance Officer (can run reports and view audit logs). Not everyone needs the same level of access.

The principle of least privilege means granting each role only the permissions needed to do its job. An incident reporter does not need to see all incidents in the system, only their own. A first-line support technician does not need to modify incident priority or close incidents in a way that bypasses review. A manager does not need to edit incident details after closure. By limiting access, you reduce the risk of accidental data corruption and make it easier to identify who made unauthorized changes.

Segregation of Duties

Segregation of duties prevents a single person from controlling a full transaction. In Incident Management, a common principle is that the person who investigates and resolves an incident should not be the only reviewer of that resolution. An incident should not be closed by the person who created it. A security incident should not be resolved by the person who caused it.

Implementing segregation of duties requires workflow design. Before closing an incident, route it to a reviewer in a different role. For high-risk changes, require the incident be reviewed by someone other than the assignee. For security incidents, add review by a security role. This adds steps to the workflow, but the audit protection is worth the cost.

Audit Logging and Evidence

Every significant change to an incident should be logged. ServiceNow maintains an audit log showing who changed what field and when. The incident record itself captures key milestones: when created, assigned, escalated, and closed. For compliance purposes, you need evidence that incidents were handled correctly. This evidence is the audit trail plus the incident record data.

Plan which incident fields should be tracked for audit purposes. Typically, you need to capture priority changes, reassignments, the resolution code and resolution notes. For security incidents, capture who accessed the record and when. Configure your system to prevent deletion of closed incidents and their audit logs. Store audit logs in a way that lets you retrieve them if needed for investigation.

Access by Role and Scope

Different roles need access to different incident scopes. A support technician in the networking team should see incidents assigned to their group, but not incidents in the database team’s queue. A support manager can see all incidents in their business unit but not in others. A global IT Security role sees all incidents tagged as security-related. A compliance officer can view reports but not modify individual incidents.

ServiceNow’s access control model uses roles, tables, and record ownership. A role grants permissions on a table, and record ownership determines which specific incidents a person can see. This means you must carefully assign roles to users and ensure that group membership is kept current. As people change teams, their role and group membership must change too.

Data Visibility and Sensitivity

Some incident data is sensitive. Security incident details should not be visible to all staff, only to security and IT leadership. Personnel issues that trigger incidents should be visible only to HR and IT leadership. Patient or customer information in incident notes should be restricted to relevant staff. If you do not define these restrictions, sensitive information might be leaked to unauthorized readers.

Use incident classifications or tags to mark sensitive incidents. Then use access control to restrict viewing of those incidents to appropriate roles. Ensure that your audit logs do not leak sensitive information either; someone viewing the audit log should not be able to see all the sensitive details if they cannot see the incident itself.

Review Cycles and Change Management

Your access control design should be reviewed regularly. At least annually, verify that everyone still has the access they need and that no one has access they should not have. When someone changes roles or leaves, remove their access. When a new role is created, define its access control at design time, not after people are working with it. Document why each role exists and what access it has, so future administrators understand the design choices.

Translate roles into platform permissions, table by table

A role model on paper becomes real only when it is expressed as access control entries on the platform. For incident handling, the work sits mainly on the incident table and the tables it references, such as the configuration items, the knowledge articles and the audit history. Each access control entry grants or denies an operation, such as read, write or create, on a table or on a single field, and it may add a condition that checks the record. Map every role to the operations it needs on each table before any entry is written, and record the mapping in the design. Entries written from memory tend to grant more than intended, because a broad read rule added for one team quietly applies to all of them.

Use field-level control for the few fields that matter

Most incident fields can be read by anyone who can see the record. A small set of fields needs tighter treatment: the security classification, the notes about a personnel matter, and in some organizations the notes that describe a patient or a customer. Field-level controls let you hide or lock those fields while leaving the rest of the record visible. Use them sparingly. Each field-level entry is another rule to test and another place where a later change can expose data. The safest design keeps restricted information in a separate, narrowly accessible record and leaves only a reference on the incident.

Protect the audit trail from the people it watches

An audit trail that the subject of the audit can edit has no value. Keep audit history readable by compliance and platform roles, and make sure no incident role can delete or change its entries. The same applies to the scripts and rules that govern incident behavior. A developer who can change an assignment rule should not also be able to approve their own change. Where the platform allows separate roles for configuration and for approval of configuration, use them, and record the approval outside the platform as well.

Plan privileged access and emergency routes

During a major incident, responders sometimes need access they do not normally hold, such as the ability to reassign records across groups or to view a restricted service. Design this route in advance rather than granting broad rights in the moment. A common pattern is a time-limited elevated role, granted by a named approver, with every use recorded and reviewed afterwards. Break-glass accounts for the platform itself should be held under separate control, tested on a schedule and never used for day-to-day work. A sound design makes the emergency route slower than the normal one, which is the point, and quick enough that responders do not look for a workaround.

1. Write down which emergency actions responders may need, and which roles already cover them.
2. Create the elevated role with a defined expiry and attach it to a request that a named approver must sign.
3. Require a note on the incident stating why the elevated role was used.
4. After the incident, review every use of the role and withdraw any access that is no longer needed.
5. Test the route once a year with a tabletop, so the approver knows how to respond when it matters.

Verify the design with real identities

Access design should be tested with accounts that resemble production, not with administrators who see everything. Create a test identity for each role, give it the same group memberships a real person would hold, and try the actions a real person would try. Include the negative cases: a reporter attempting to see another team’s incident, a resolver trying to close a security record, a manager trying to alter a closed record. A test that only confirms what should work is an incomplete test. Record the results with the role, the action, the expected outcome and the observed outcome, and keep the record with the design.

Frequently asked questions about incident access

Should security incidents sit in the same table as other incidents?

Often yes, with a classification and access rules that restrict who can see them. Splitting security incidents into a separate table can make correlation with other incidents harder, and it adds a second process to maintain.

What about a contractor who needs a restricted queue for a short spell?

Grant a time-limited role tied to the contract end date, with the approval recorded, and review it at the end of each period. Contractor accounts that outlive their engagement often show up in access reviews.

Can the test copy hold real access rules?

A non-production copy is useful for testing, but it must be masked or restricted, or it becomes a path around the production controls. Restrict its access to the testers who need it.

What is the first access review to run after go-live?

Compare the list of people with the incident roles against current employment and group membership. Remove what is no longer needed, then review the restricted fields and the elevated roles.

The access rules are easier to get right when they are tested against real identities, and the wider platform rules are covered in the guidance on reviewing platform access. Keep the audit design aligned with the audit trail evidence guidance, and review standing access with the access recertification approach.