ServiceNow Security Operations: Security and Access Design

Principles of Security Operations Access Control

Security Operations (SecOps) gives security analysts and incident responders visibility into threats, vulnerabilities, and security events across the organization. Access to Security Operations data must be carefully controlled because the module contains sensitive information: which systems are vulnerable, what threats were detected, and how incidents were handled.

The design should follow three principles: least privilege (users have access only to the data and actions they need), segregation of duties (no one person can both detect a threat and approve its remediation without oversight), and audit evidence (every access decision is logged so you can prove later who did what and when).

Role Model for Security Operations

Security operations uses five primary roles: a SOC Manager oversees the team and escalates decisions, Security Analysts detect and investigate threats, Incident Responders execute remediation (patch systems, isolate compromised machines, reset credentials), a Compliance Officer monitors for regulatory violations, and an IT Admin implements system access decisions.

A SOC Manager has authority to acknowledge incidents, set priority, and assign investigation to analysts. A Security Analyst can view all security events and vulnerabilities, search data to investigate suspected breaches, and recommend remediation but not execute it. An Incident Responder has authority to execute remediation: disable accounts, kill processes, isolate systems. A Compliance Officer can view security metrics and generate reports but cannot modify configurations. An IT Admin implements access changes decided by others (disable an account, revoke SSH keys).

Least Privilege Implementation

Define the minimum permission set for each role. A Security Analyst investigating a breach needs to read incident data, search event logs, and run diagnostic queries, but should not be able to create or delete incidents (that’s the SOC Manager’s role). A Patch Administrator needs access to the vulnerability management module but does not need access to incident investigation or threat intelligence data.

Use role hierarchies if available. A senior analyst might inherit permissions from the Analyst role and add manager-level permissions for escalation. This reduces role duplication and makes role management clearer.

Periodically review role assignments. In many organizations, team members accumulate roles as they change projects; roles are rarely revoked. Conduct quarterly access reviews where managers confirm each team member’s role is still necessary for their current job.

Segregation of Duties in Incident Response

Two key segregations protect incident response integrity. First, the person who detects a threat should not be the sole authority to approve its remediation without review by a peer or manager. A Security Analyst detecting a compromised account should flag it for a manager to review and approve remediation, ensuring the detection is real and the proposed fix is proportionate.

Second, the person who responds to an incident should be distinct from the person who investigates whether the response worked. An Incident Responder isolates a compromised system; a separate analyst verifies isolation was effective and the threat is actually contained. This separation prevents both cover-ups (hiding a failed response) and approval bias (approving your own work without scrutiny).

For small teams with only two or three responders, this segregation may not be practical. Document the exception and require additional oversight (a second responder reviews each remediation action) to compensate.

Access to Sensitive Data

Not all analysts need access to all data. A Vulnerability Management analyst needs to see vulnerability scans but may not need access to incident investigation records. A Threat Intelligence analyst curates indicators of compromise (malicious IP addresses, file hashes) but doesn’t need access to internal incident details.

Implement data filtering based on role. If your organization operates in multiple geographic regions, analysts in EMEA should not have unfiltered access to incidents or vulnerabilities in APAC unless there is a business need. This reduces the blast radius if an analyst account is compromised.

Use a data access control list (ACL) to define which data each role can read, create, update, or delete. In ServiceNow, this is typically implemented through query conditions that filter records based on the user’s role or assignment group. Document the business reason for each restriction so you can re-evaluate it periodically.

Audit Evidence and Logging

Enable audit logging for all privileged actions: creating, updating, or deleting incidents; modifying remediation plans; revoking access; changing alert thresholds. Log the user, timestamp, what changed, and the old and new values. Review audit logs monthly for suspicious patterns (one analyst closing all high-severity incidents without investigation, one responder executing remediation for incidents they themselves opened).

Archive audit logs according to your compliance requirements. Many regulations require preservation of security logs for a set period. Set up automated archival to a system separate from the operational database so operators can’t tamper with historical logs.

Use audit logs not just for compliance but for continuous improvement. If audit logs show that a particular remediation step is always performed by one person and fails when that person is unavailable, cross-train others to reduce the dependency.

Third-Party Access and Exception Management

If external security vendors (incident response consultants, managed security service providers) need access to Security Operations for investigation or monitoring, establish a formal access request process. Approve access for a limited, defined duration, specify which data they can access, and require the vendor to sign a data handling agreement confirming they will not retain data after the engagement ends.

Maintain an exception register for users with access beyond their normal role (a vendor gets temporary Incident Responder access, an executive gets read-only access to dashboards). Review exceptions monthly. When an exception is no longer needed, revoke it immediately.

Common Access Design Mistakes

Giving all analysts the same permission set. In reality, threat intelligence analysts, incident investigators, and vulnerability managers need different access. Tailor access to the specific workflow each role performs.

Failing to segregate incident detection from approval. If the same person detects and approves remediation without review, you lose a valuable control point and risk both missed threats and unnecessarily disruptive responses.

Not reviewing access regularly. Over time, team members move roles and access accumulates. A former threat analyst who moved to a different team may still retain access they no longer need. Quarterly access reviews catch these cases.

Designing access for the first week of an incident, not only the steady state

Access designs for security operations are often written for a calm Tuesday. The harder test is the first hour of an incident, when a contractor needs read access to a case, an executive wants a live view of containment progress, and an analyst from another region has to see an affected host. If the design only covers the standing roles, the team can grant exceptions in a hurry, and those exceptions can outlive the incident. Design the emergency path on purpose: name who can grant temporary access, what the maximum window is for that grant, and what evidence the grant must leave behind. Where a grant changes what a user can read in the first place, the access control list explanation is the reference to check.

A second test is the boundary between seeing and acting. Read access to a case often exposes more sensitive detail than people expect, including the names of affected users, the internal addresses of compromised hosts and the contents of intelligence notes. Separate the permission to view a summary from the permission to open the underlying evidence, and make the second one narrower.

Temporary access during an active event

Steps for building an emergency access path

1. List the roles that can be granted temporary access in an incident, and the one person who can approve each kind of grant.
2. Create a standard request that captures the case reference, the reason, the scope and the expected end time. Keep it short enough to complete at speed.
3. Build the grant as a time-limited assignment rather than a permanent role change, so expiry is the default and extension requires a new decision.
4. Set an alert for any grant that has not been reviewed by its end time, and send it to the approver rather than to a shared inbox.
5. After each incident, compare the list of grants with the list of people who actually opened the case, and remove any grant that was never used.

Protecting evidence from the people who are allowed to see it

Evidence integrity is an access question as much as a forensic one. The audit trail evidence article covers the logging side of this. The people who view an artifact should not be the only people able to change its description, and nobody should be able to delete an attachment from a closed case. Where a platform allows attachments to be replaced, decide whether that is ever acceptable. In many regulated environments the answer is that a replacement is recorded as a new attachment with a reference to the one it supersedes, and the original stays in place.

Think also about what happens to access when a case is reopened months later. Permissions that were granted for the original investigation may no longer match the people now involved. Periodic cleanup of standing permissions is the subject of the access recertification article. Reopening should trigger a fresh review of who can see the case, rather than inheriting the earlier list.

Where access designs often go wrong

• Temporary grants that become permanent because the expiry date was never entered, or because the expiry field is optional in the request form.
• Shared service accounts used by integrations that can also read every case, which means a leaked integration credential exposes the whole queue.
• Reporting roles that were copied from the analyst role and quietly gained the ability to change assignments.

Questions about access that come up after a first design

Should a vendor ever receive standing access to security operations?

Standing access is hard to justify for an outside party. A managed service provider may need it for monitoring, but that is often better expressed as an integration with narrow scope than as a user account with a broad role. Review any standing vendor access at a fixed interval and tie it to a named contract.

How should break-glass access be handled in the platform?

Keep a small number of break-glass accounts, store their credentials under dual control, and alert on every use. Test the alert at least once a year so the team knows it works. A break-glass account that nobody has tested is a documented risk rather than a control. A broader review of platform permissions is covered in access controls review.

Next step

A tabletop exercise run against your actual role list can expose emergency grants that are wider than anyone intended.

Security Operations access design: table names, prefixes and role checks

Security Operations access in ServiceNow rests on a few record types, each with its own table and number prefix, and on ACL rules that decide who can read or change them. The deciding fact is to design access per table, since a security incident and a vulnerable item are different tables with different audiences.

These are common out-of-box names, so check them on your own instance and release; the sn_ tables also depend on which security plugins are active, and labels change between releases.

Access follows the table, so a role that opens security incidents does not by itself open vulnerable items. When two teams share a table, such as analysts in different regions, filter by a field on the record with a query business rule or an ACL condition, or use domain separation where the instance is licensed for it.

Example (hypothetical): a vulnerability team wants a patching group to see only the vulnerable items for its own servers. The platform team gives the group read access on that table, adds a condition matching the item’s assignment group, and leaves the security incident table closed to them. Each week a reviewer lists members added to the group recently, using the created date on the membership record.

What do the SIR and VIT prefixes mean?

SIR is the number prefix on a security incident, held in sn_si_incident, and VIT is the prefix on a vulnerable item in sn_vul_vulnerable_item. Both depend on the product being installed, and an instance can change a prefix, so confirm against your own number maintenance settings. See vulnerability response for the wider module.

Where can you see who changed a security incident field?

Auditing records field changes in sys_audit, but only for tables where auditing is turned on, and individual fields can be excluded. Confirm auditing is on for the security incident table before relying on it as evidence, and prove it by editing a test field. The security operations guides give context.

How do you review who can reach security incidents?

List the roles the table’s read rules require in sys_security_acl, find the groups that hold those roles, then list each group’s members from sys_user_grp_member. Compare every name with an approval record and remove anyone without one. Managed help is described under security operations and incident response.