Security & Access Controls | ServiceNow CSA Part 2

Section 1

ServiceNow Security Model Overview

ServiceNow enforces security at multiple layers, each serving a distinct purpose. Understanding how these layers interact is essential for both the exam and real-world administration.

Three Layers of Security

🚪

1. Role-Based Security

Controls which modules and applications appear in the navigation menu. Roles determine what a user can see in the left-side navigator. If you don't have the role, the module doesn't appear.

Example: The itil role exposes Incident, Problem, and Change modules in the navigator.

🔒

2. ACL-Based Security

Controls who can read, write, create, or delete specific records and fields. ACLs operate at the database layer, enforcing rules even when accessed via REST API or direct queries.

Example: An ACL on incident[READ] determines who can read incident records.

📋

3. Data-Level Security

Row-level security through conditions and scripts on ACL rules. Restricts which specific records a user can access, even within the same table.

Example: A condition ensures users only see incidents assigned to them.

Key Principle: ServiceNow security is additive for roles (any matching role grants access) but uses a waterfall for ACLs (most specific matching ACL wins and evaluation stops).

Castle Analogy: Think of security as a castle. Roles are the main gate — they determine whether you can enter the application at all (is the module visible?). ACLs are the room locks — once you're inside the castle, they control which specific rooms and files you can access. You need both: the gate key and the room key.

Section 2

Access Control Lists (ACLs) — Introduction

Access Control Lists (ACLs) are the primary security enforcement mechanism in ServiceNow. They are database-level permission rules evaluated on every data access attempt.

ACLs are stored in the sys_security_acl table
Navigate to: Security > Access Control (ACL) or type sys_security_acl.list in the filter navigator
Required role to create/modify ACLs: security_admin (or admin on older instances)
ACLs are evaluated every time a user attempts to read, write, create, delete, or execute

ACL Anatomy

Every ACL rule contains the following fields:

Field	What It Means	Example
Type	Scope of the ACL: table, record, or field	`table`
Operation	The action being controlled: read, write, create, delete, execute	`read`
Name (Table.field)	What is being protected — table name, optionally followed by a field name	`incident.caller_id`
Role	The role(s) a user must have; multiple roles are OR'd together	`itil`
Condition	Optional GlideRecord condition or JavaScript expression that must evaluate to true	`assigned_to=javascript:gs.getUserID()`
Script	Optional server-side script returning `true` (allow) or `false` (deny)	`return gs.hasRole('manager');`
Admin overrides	Whether admin users bypass this ACL. Default: true (admins bypass). Set to false to enforce for all users.	`true`

ACL Types

Table ACL

Controls access to entire records in a table. Most commonly used type.

Example: incident[READ]
Who can read any incident record?

Field ACL

Controls access to a specific field within a table. Used to protect sensitive data columns.

Example: incident.salary_info[READ]
Protect a sensitive field on the form.

Record ACL

Controls access to specific records via a condition. Implements row-level security — filters which rows a user can access.

Example: Only incidents where assigned_to = current user.

ACL Operations

read

View records or field values

write

Modify existing records

create

Insert new records

delete

Remove records

execute

Run scripts or REST APIs

Exam Must-Know — ACL Three-Part Check: When evaluating an ACL, ServiceNow checks three things in sequence:

Does the user have the required ROLE?
Does the optional CONDITION evaluate to true?
Does the optional SCRIPT return true?

ALL three must pass for access to be granted. If any one fails, the ACL denies access.

Section 3

ACL Evaluation Order (CRITICAL for Exam)

ServiceNow evaluates ACLs from most-specific to least-specific. The first matching ACL wins — evaluation stops as soon as a match is found.

Priority Order

Priority	ACL Pattern	Description	Example
1 — Most Specific	`record.field`	Exact table + exact field + record condition	`incident.caller_id[READ]` with condition
2	`table.field`	Specific table, specific field — no record condition	`incident.caller_id[READ]`
3	`table.*`	All fields on a specific table	`incident.*[READ]`
4	`*.field`	A specific field name on any table	`*.salary_info[READ]`
5 — Least Specific	`.`	All fields on all tables — the global fallback	`.[READ]`

Exam Trap: If a more-specific ACL denies access, the less-specific ACL is NOT checked. The most specific matching ACL wins and evaluation stops immediately — even if a broader ACL would have allowed access.

What Happens When No ACL Matches?

Fail-Closed Security: If no ACL rule matches for a non-admin user, access is DENIED by default. ServiceNow implements a fail-closed (deny-by-default) security model. You must explicitly grant access — it is never implicitly granted by absence of rules.

Admin Exception: Admin users bypass ACL evaluation by default. This means admins can always access all records unless you explicitly set Admin overrides = false on an ACL. Use this for highly sensitive data that even admins shouldn't casually access.

Section 4

Role-Based Access Control (RBAC)

Roles are named collections of permissions that control navigation visibility and act as prerequisites within ACL rules. They are the first gate a user passes through.

Roles control the visibility of modules and applications in the left navigation bar
The itil role grants access to Incident, Problem, and Change Management modules
Create custom roles: User Administration > Roles > New
Roles can contain (include) other roles — creating a role hierarchy
Users can have multiple roles; role access is additive (any matching role grants the permission)

Role vs. ACL Interaction

Roles and ACLs work together as complementary layers — one affects navigation visibility, the other controls data access.

Layer	Controls	Example
Role → Navigation	Whether the module appears in the left-side navigator	`itil` role makes "Incident > All Incidents" visible in nav
Role → ACL Condition	The role check inside an ACL rule determines record access	ACL rule: incident[READ] requires itil role
Both Together	Full access path: nav shows the module AND ACL allows reading records	User can navigate to Incidents AND see the incident list

Common Misconception: A user might have a role that shows a module in navigation, but an ACL on the underlying table could still block them from reading records. Both layers apply independently. Removing the role hides the module but does not prevent direct URL or API access — only the ACL does that.

Section 5

Row-Level Security (Data-Level ACLs)

Row-level security restricts access to specific records within a table rather than the entire table. It is implemented through the Condition and Script fields on an ACL rule.

How It Works

The Condition field on an ACL accepts a GlideRecord condition or JavaScript expression
The expression has access to the current object (the record being evaluated) and gs (GlideSystem)
Example: Only allow reading incidents where the current user is the assigned agent
The Script field handles more complex logic and must explicitly return true; or return false;

Critical Method: gs.getUserID() returns the sys_id of the currently logged-in user. This is used heavily in ACL conditions to implement row-level security. Know this method — it appears frequently on the exam.

Common ACL Condition Patterns

// User can only see their own records (Condition field)
assigned_to=javascript:gs.getUserID()

// User can see records assigned to any of their groups
assignment_group=javascript:gs.getMyGroups()

// Check if user has a specific role (Script field)
javascript:gs.hasRole('itil')

// User is the caller OR the assigned agent (Script field)
javascript:current.caller_id == gs.getUserID() || current.assigned_to == gs.getUserID()

Condition vs. Script: Use the Condition field for simple database-style conditions (field = value). Use the Script field for complex logic requiring multiple checks, boolean operators, or method calls that return true/false. Scripts run server-side and have full API access.

Section 6

UI Policies vs. ACLs

This is one of the most important distinctions on the CSA exam. UI Policies and ACLs look similar — both affect what users can do with fields — but they operate at completely different layers.

Aspect	UI Policy	ACL (Access Control)
Runs on	Client (browser — JavaScript)	Server (database layer)
Enforcement	Client-side JavaScript execution	Server-side database evaluation
Can be bypassed	Yes — REST API, direct DB calls, disabling JS	No — enforced at the database level always
Primary purpose	UX behavior: field visibility, mandatory, read-only	Security: record and field access enforcement
Controls	What a user sees and can interact with on a form	What a user is permitted to access in the database
Applies to	Form UI only (not list views, API, integrations)	All access paths: UI, API, integrations, scripts
Use case example	Make "Resolution Notes" mandatory when State = Resolved	Prevent non-managers from reading salary fields

Critical Exam Point: UI Policies are NOT security controls. They run in the browser and can be bypassed by direct REST API calls, integrations, or anyone who disables JavaScript. If you need to enforce security (e.g., hide a sensitive field), you must use an ACL. Use UI Policies for UX behavior only.

Section 7

High Security Plugin

ServiceNow offers a "High Security Settings" plugin that adds an enhanced layer of security controls on top of the base platform.

What It Provides

Password Policies

Enforces password strength rules: minimum length, complexity requirements, expiration policies.

Session Controls

Configurable session timeouts and idle session expiration to reduce exposure from unattended sessions.

Account Lockout

Lockout policies after a configurable number of failed login attempts to prevent brute-force attacks.

IP Restrictions

Restrict instance access to specific IP ranges or subnets — useful for enterprise environments.

Enhanced Auditing

More granular audit trail for security-sensitive events and admin actions.

Stricter Auth

Enables stricter authentication mechanisms and multi-factor authentication support.

CSA Exam Scope: For the CSA exam, know that the High Security Plugin exists and adds additional security settings like password rules, session timeouts, and lockout policies. You do not need to know how to configure each setting in detail — awareness is sufficient at this level.

Section 8

Exam Traps & Key Reminders

This section consolidates the most frequently tested ACL concepts and common wrong-answer traps on the CSA exam.

Trap 1 — Evaluation Order: ACL evaluation runs from most-specific to least-specific. The first matching ACL wins and evaluation stops. Do not assume a permissive wildcard ACL will "catch" a user denied by a more-specific ACL.

Trap 2 — Admin Override: The admin role bypasses ACL evaluation by default. To make an ACL also apply to admin users, set Admin overrides = false on that specific ACL. This is how organizations protect highly sensitive data (e.g., salary records, HR data) from casual admin access.

Trap 3 — Field ACLs and Table ACLs are independent: A user needs BOTH table-level read permission AND field-level read permission to see a field's value. Passing the table ACL does not automatically grant access to all fields — field ACLs are checked separately.

Trap 4 — Deny by Default: If no ACL rule matches for a non-admin user, access is DENIED. This is the fail-closed model. Never assume "no rule = allow."

Debugging ACL Issues: When troubleshooting access problems, use the ACL Simulator: navigate to Security > Diagnose > ACL. You can simulate access for a specific user to a specific record and see exactly which ACL rules are matching and why. Also check the system log (syslog.list) for ACL denial messages.

Putting It All Together:

User navigates to a module → Role check: does the nav item appear?
User opens a record list → Table ACL [READ]: can they see any records?
Row-level ACL condition → Record ACL: which specific records can they see?
User opens a record form → Field ACLs [READ]: which fields are visible?
User tries to save → Table ACL [WRITE] + Field ACLs [WRITE]: can they modify?